Ignite SQL engine cannot be considered as a competitor (in a single-node scenario) to old-good RDBMS like Postgres or MySQL. Those DBs have been being developed for decades and are optimized for single-machine deployments. While our efforts (Ignite community) were put into distributed optimizations when an application has to scale out and utilize RAM in the distributed fashion. That's why we have that recommendation to avoid any misunderstanding. Probably, it needs to be rewritten a bit for more clarity.
Btw, if you are around Silicon Valley, step by my session at PostgresConf this week: https://postgresconf.org/conferences/SV2019/program/proposals/postgresql-with-in-memory-computing-faster-transactions-and-analytics-d6bb1225-4721-46ce-beda-e44f5e7c333e As for your specific case, I think that a primary bottleneck is a number of JOINs. It makes sense to rewrite this query first and then scale-out for bigger benefits. Ivan Pavluknin, Stan Lukyanov, Pavel Vinokurov, could you folks please check this thread out and this repo suggesting any optimizations? https://github.com/spoutnik-be/h2-ignite-perf.git - Denis On Mon, Sep 16, 2019 at 6:08 AM spoutnik_be <[email protected]> wrote: > About the quote on Stackoverflow: > "Ignite/GridGain is optimized for multi-nodes deployments with RAM as a > primary storage. Don’t try to compare a single-node GridGain cluster to a > relational database that was optimized for such single-node configurations. > You should deploy a multi-node GridGain cluster with the whole copy of data > in RAM." > > Not sure how to interpret the above statement. The support for SQL is an > attractive feature of Ignite/Gridgain, but if it doesn't perform on a > single > node with little data I don't see how it will perform on a multi-node > cluster. > > What would be then your recommendation? Should we implement a SQL converter > to translate queries into something else Ignite could run faster? > > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
