NoSQL databases often make tradeoffs by relaxing some of the ACID properties of relational databases for a more flexible data model that can scale horizontally. This makes NoSQL databases an excellent choice for high throughput, low-latency use cases that need to scale horizontally beyond the limitations of a single instance.
Right. So it got speed at the price of consistency. Which can be a fair tradeoff to make, but it’s exactly that: a tradeoff. Depending on the use case it may or may not be a wise choice.
NoSQL requires a change in behavior one which people aren’t hacking the database only using provided apis to persist information that enforces data integrity and other business process workflows.
Users suffer when the development process fails to acknowledge traffic growth until brought too light as a real problem. A large portion of industry lacks the means of true observability into this altogether. A problem that can somewhat be eradicated by considering scale from the start and using modern tools to facilitate it more easily so users aren’t left holding the bag. Many scaling and performance problems are not simple to solve once the app has been built and is in production use. This is especially true for older legacy platforms like monolithic cms. Instead of actually solving the problems and changing the architecture bandaids on top of band aids like caching are implemented that make the software more and more complex and get in the way of development. The inherit scalability, availability, flexibility of NoSQL solutions have a significant role to play in building architectures robust enough to scale to accommodate any traffic needs without a whole bunch of bandaids on top.
There are also some none json solutions in this realm as well. If you want to stick with a relational data model with tables Cassandra is a highly available, scalable alternative to traditional relational databases.
How many apps (in percentage) need such big data? I have no clue where you really need high scalable databases, except you are google and gather all information you can get.
Surely you are not suggestion all financial institutions that require transactions in order to work because otherwise money might be lost into thin air are “hacking the database”, are you?
With that in mind traditional databases are one of the most expensive things to change. The more applications that rely on a database the more difficult it will be to modify the existing structure without needing to update the other apps in the process. Many times organizations with large databases don’t even have an understanding of all the apps that might be using a single database. Much of the time the people who manage the database don’t even know what apps are being used nor the business logic necessary to maintain workflow integrity. On the other end a team might modify the database with unintended consequences for another team that they are unaware of. I would diagree that its never to early to optimize data storage and consider future data and traffic needs. The same rules about premature optimization in app code are not as relevant to the data model. Its important to have a flexible robust scalable data model in the first place otherwise you will likely need to rewrite the app, implement bandaids, undergo large and expensive migration process full of risks as needs grow.
Blockchain is a solution looking for a problem, and a poor one at that.
All these “old” techniques exist for a reason, and all the new ones do to. I’m all in favor of new stuff, but not in favor of abandoning everything to go to new stuff because it’s new. And I’m especially not in favor of recommending only new things to people who are just starting out. Things that have been around longer have more information online, more fleshed out documentation, more people to ask questions about them, etc. Which is precisely what you want when you’re starting out.
There’s nuance and tradeoffs all around. Sometimes and old tool simply is best for the job, because it’s been doing it for ages without problem and all initial problems have been fixed. Which is always the question what you encounter when you jump on the bandwagon of a new shiny thing.
I’m not saying here that one should never use new techniques. I’m saying you should consider the problem at hand and see which solution fits best instead of always using a hammer because everything looks like a nail.
Many NoSQL technologies have been around for over a decade including Mongo and CDNs. They just appear “new” so to those who have not embraced anything new in the past decade.
For front-end development I would opt to focus on emerging JavaScript technology and less on storage. That can be realized by using simpler storage options that don’t require a completely other skill set like relational database architecture.
Funny you mention that because that is what applying a relational database or monolithic cms, php framework to every problem is. Using the same tool over and over not considering, researching more viable tools in the modern space.
New comers can capitalize marketability embracing modern technologies that legacy developers are unfamiliar and reluctant to learn. The cool new projects are being built with modern solutions not age old legacy technology. This includes a heavy dose of alternative legacy database solutions and the cloud.
The focus on this forum in regards to php and relational databases is a rapidly shrinking sector of the market. The primary employment opportunities in this shrinking space are those maintaining monolithic php cms’s not building cool new software. New software solutions for machine learning, ai, socal media, commerce, block chain are not being built with the technologies proliferated on this forum with the exception of Javascript. They are being built with much more modern, cloud driven stacks. It does new comers a huge disservice to set them on a path of these technologies like php and legacy databases. These are no longer highly marketable skills except in the case of subject matter except in a monolithic cms platform.
Relational databases have been around since the 60s or so. In that sense NoSQL is still new.
Agreed. That shouldn’t be done either.
I think most people are because they already landed a PHP job and need some guidance on how to do things. Sure, it’s good for them to broaden their horizon, but migrating an existing system to a new technology is usually a really hard sell to management, mostly because there are no tangible benefits to them and because full rewrites pose a pretty huge risk.
But indeed, it might be interesting for them to see new stuff, play around with it and maybe land a different job next time. No argument here.
The tangible benefit of moving to the cloud and investing in green software development is reduction of a companies carbon footprint. All major players in the cloud space have sustainability initiatives. AWS data warehouses are on track to be running on 100% renewable energy by 2025. Governments are also making moves in the shadows to require companies to comply with sustainability measures. Companies should invest now knowing what is coming down the pipeline. Building efficient, low carbon software solutions requires a change in behavior that gone unlearned, un-embraced will end careers and companies in the near future. Climate action and justice is going to be engrained into the global economy with software development no exception. There will be real consequences to implementing clunky old energy inefficient legacy software solutions. Furthermore, building software on top of modern energy efficient tools often times leads to lower ongoing hosting costs. For example, migrating a WordPress website to a static site eliminates the need for a server that is always running and massively inefficient. So its not only good for the environment to consider sustainable software design but also the pocket book