In my opinion it's overhyped. I'll probably take point hits for claiming it, but so be it. Let the truth ring.
Why copy techniques meant for Netflix and Facebook when your org or app is most likely 1/1000th their size. Phallic size jealousy at work.
Most concurrent and parallel work can and should be done on a true-and-tried RDMBS for most orgs and apps. Use transactions/rollbacks properly and let the RDBMS manage most the grunt work instead of reinvent the wheel in app code.
If you want extreme scale, most data in memory, such as a search engine processing millions of documents running data pipelines, then RDBMS isn't the way to go. For other MVC types, for a reasonable scale out, straight forward models with RDBMS should do.
Note that existing RDBMS are gradually adding and improving their text search engines. Of course there will always be specialized situations that need dedicated high-end text search engines.
Comments
In my opinion it's overhyped. I'll probably take point hits for claiming it, but so be it. Let the truth ring.
Why copy techniques meant for Netflix and Facebook when your org or app is most likely 1/1000th their size. Phallic size jealousy at work.
Most concurrent and parallel work can and should be done on a true-and-tried RDMBS for most orgs and apps. Use transactions/rollbacks properly and let the RDBMS manage most the grunt work instead of reinvent the wheel in app code.
K.I.S.S. and use-the-right-tool-for-the-job.
If you want extreme scale, most data in memory, such as a search engine processing millions of documents running data pipelines, then RDBMS isn't the way to go. For other MVC types, for a reasonable scale out, straight forward models with RDBMS should do.
Note that existing RDBMS are gradually adding and improving their text search engines. Of course there will always be specialized situations that need dedicated high-end text search engines.