NoSQL debate: All content tagged as NoSQL debate in NoSQL databases and polyglot persistence
Marco Arment about switching from familiar systems or programming languages to better ones:
The fear of making the “wrong” choice actually makes the familiar, mastered PHP more attractive. […] If you can get PHP programmers to agree that they need to stop using it, the first question that comes up is what to use instead, and they’re met with a barrage of difficult choices and wildly different opinions and recommendations.
The same problem plagues anyone interested in switching to Linux (Which distro? Which desktop environment? Which package manager?), and the paralysis of choice-overload usually leads people to abandon the choice and just stick with Windows or OS X. But the switching costs of choosing the “wrong” programming language for a project are much larger.
Once you master a programming language or system you start seeing the other options from a different perspective. It doesn’t mean you have a better or an objective perspective though. What you’ve got is a new dimension you are considering in all decisions: familiarity. Every other option you have will go through your familiarity filter: does it feel familiar? does it allow me to do what I’ve been doing all this time? does it work in a similar way?
You might think that using a familiar system is all about productivity. I think that is only partially true. A familiar system doesn’t come with a learning curve and so in the early stages it feels productive. But many times you’ll just have to write over and over again the same things, avoid the same traps and made the tweaks you’ve learned. In a way this part of being productive feels like repetition.
But what all these have to do with databases? The answer is probably obvious.
Familiarity is in so many cases the main reason new systems start with a relational database. It feels familiar. It is familiar. As your application grows and new features are needed there will be cases when the relational database would become a less optimal solution. But in the name of familiarity, you’ll be tempted to stick with it. Make a change here and there, declare a feature too complicated, tweak it, optimize it. Repeat.
After a while, taking a step back might make you realize that what you’ve built is not anymore familiar. Or maybe it’s still familiar to you, but to a new project team member it will feel different and new. Or maybe very similar to a different database that you could have started with.
The costs of sticking with familiar programming languages, systems, or databases could be much larger than you’d think of.
Original title and link: Addiction to Familiar Systems ( ©myNoSQL)
Developer adoption matters above all else in the early days of technological change. That is why all of these companies are placing big bets on training and documentation programs.
I have asked myself: why developer adoption? Was new technology adoption always targeting developers? And I think I have a couple of answers:
- targeting developers is the easiest way to get feedback from people that will use your product. Keep in mind that business solutions rarely rely directly on technology. They usually rely on their technical teams which rely on technology, so most of the time your product’s users will be the developers, not the businesses
- more importantly, developers will quickly come up with use cases and scenarios where your product fits (nb they will also complain a lot about what doesn’t work). You could then use these use cases/scenarios to build your pre-sales/sales pitches
- last, but not least, developers will do a part of the marketing and PR for you. If they don’t, then your product might not be as useful as you thought of it.
On the other hand, if your product positioning is not very clear, betting your adoption on developers only might also be interpreted as a a weakness sign (as in “hey, they have no idea what their product should do”). Some will see your product as a vitamin instead of a painkiller. Not to mention, that developers will say both good things, but also a lot of things about what they don’t like and where your product sucks.
Interesting article from Xeround Avi Kapuya ☞ NoSQL: The Sequel. Couple of comments though:
In other words, in SQL, the data model does not enforce a specific way to work with the data — it is built with an emphasis on data integrity, simplicity, data normalization and abstraction, which are all extremely important for large complex applications.
I’d say that data normalization is not a goal per se, but a solution to a problem (data duplication, frequent updates to common entities). But what if this solution is introducing another bigger problem (read JOINs)?
The NoSQL approach presents huge advantages over SQL databases because it allows one to scale an application to new levels
Plus it may give you more flexibility in your data model, plus it may be a better (as in operational, complexity, performance, etc.) storage for different formats of data.
Why not NoSQL
At the system level, data models are key*. Not having a skilled authority to design a single, well-defined data model, regardless of the technology used, has its drawbacks.
Actually I think the reality might be a bit different. Because NoSQL imposes a “narrow predefined access pattern” it will require one to spend more time understanding and organizing data. Secondly, the final model will reflect and be based on the reality of the application, on not only on pure theory (as is the case with most initial relational model designs).
At the architecture level, two major issues are interfaces and interoperability. Interfaces for the NoSQL data services are yet to be standardized.
The interface limitation is a temporary issue in terms of getting more/better/quicker tooling support and probably a longer term issue for developers needing to learn different models. But as we’ve agreed, NoSQL has a small, predefined access mode and so we are not talking about learning completely new languages.
Personally, I think the real issue is steep learning curve of understanding each of these NoSQL databases semantics and operational behavior then not having a common API.
Interoperability is an important point, especially when data needs to be accessed by multiple services.
I’m not seeing the problem here. As far as I know each relational database is coming with its per-language drivers. On the NoSQL side, there are already quite a few products using standard protocols.
Moving to the operational realm, here, from my experience, lies the toughest resistance, and rightfully so… The operational environment requires a set of tools that is not only scalable but also manageable and stable, be it on the cloud or on a fixed set of servers. […] Operation needs to be systematic and self contained.
Now, this is completely the other way around. If you read any large scale application story, you’ll notice the pattern: the operational costs where a significant factor in deciding to use NoSQL. Just check the stories of Twitter, Adobe, Adobe products, Facebook. Complexity is a fundamental dimension of scalability and right now the balance is towards NoSQL databases .
It is my opinion that a SQL database built on NoSQL foundations can provide the highest value to customers who wish to be both agile and efficient while they grow.
Unfortunately I don’t think that’s actually possible or at least not for all solutions. But If we just want some common access language, we will probably get it.
If, on the other hand, what we want is more tunable and scenario specific engines, we will probably get these too. (nb: as far as I’ve heard the PostgreSQL community is learning a lot from the various NoSQL databases and trying to bring in as many of the good ideas they can).
My conclusion is simple. As with programming languages where we are not stuck with COBOL, polyglot persistence is here to stay and it’ll only get better.
But lot of people asked me why I am part of Zynga database team when there is no MySQL being used […]
As a consultant, I help lot of other companies to scale using NoSQL systems apart from MySQL especially on large data handling; as the data store solution should help to scale the systems to yield the desired results; especially MySQL should be used for typical OLTP workloads and combination of MySQL and NoSQL or any other data warehouse clusters for analytics and/or OLAP workloads by combining with right application and caching components based on the business model and how the data is generated, stored, accessed and processed. ☞ Venu Anuganti
For the majority, technology is just a small part towards the business goals. As engineers, we should stop being religious about our technical fetishes and deliver value.
That doesn’t mean though, we cannot continue having our techy tee parties (read with tons of beers) where we are bashing every other product.