Open source data is divided into two factions, NoSQL enthusiasts like to publish a lengthy criticism of relational database limitations, MySQL enthusiasts stubbornly defend the health relational database-insist that the data neatly stored in the table.
You'd think the two sides would never get along, but in fact, tens of thousands of companies have been trying to combine relational and relational databases, and have tried it many years ago.
But the development of new technologies is often antithetical to the technology of the past. When NoSQL developed, the name of the light sounded like the end of the relational database, but it was impossible, at least not so fast.
The success of Craigslist
craigslist seamless integration of structured and unstructured data retrieval is a good example. In the past, the company has been using MySQL to deal with frequent tasks and classified ads.
Despite the heavy workload, MySQL can easily complete this task. The need for NoSQL is generated only when the archived data reaches a record level. As a result of management requirements, Craigslist must archive all historical data-even the ads for Austin's dingy, high-priced apartments during SXSW.
If a relational database relies on the logic of the data, the changes to the front-end architecture will inevitably affect the archived data. This is a high-risk, high time consuming process, and it can cause downtime loss. Imagine updating a MySQL server cluster with 1 billion records!
Craigslist discovered the need to process two types of data in discrete ways-current and historical data. Craigslist may have turned to MongoDB to help cope with the growth of the data, but the NoSQL run with MySQL has never had a problem, indicating that MySQL and NoSQL can be well combined.
Open Source Alliance
An increasing number of application developers and hosting providers recognize that NoSQL and MySQL have always been open source alliances and have not been hostile to each other because of database types. The point is that data is data that should be used to service applications and users and should not be limited by backend databases.
More and more Rackspace customers find themselves facing the same situation as Craigslist. When relational databases cover all their data domains, they build their own data structures, and now they are in the application age.
Reaching 1 million customers took years, and now it only takes a few weeks, and social sharing and real-time querying have put new demands on the data-and the infrastructure that supports it-a series of changes that have brought them up to 1 billion of the amount of data per month.
They are not necessarily digging MySQL databases, but they need to add data engines. To increase the speed and flexibility of the database, MongoDB, Cassandra, or redis (such databases) are included in the data structure. However, these open source databases are unlikely to be used to store user confidential information or financial records, as they must always be consistent.
At present, it is common for technology companies to employ traditional relational database administrators and to build a NoSQL application development team. Sometimes, the same application based on relational and non relational databases can even communicate in the Web layer.
Past database administrators must work with a new generation of developers who use NOSQL programming to make decisions about deployment and architecture (and perhaps those database administrators and developers can become friends).
Perhaps such companies don't even have database administrators, who outsource all applications and data tiers to managed service providers, so they have to take full advantage of deep expertise and teamwork to cross the gap between SQL and NoSQL.
Select one? or both?
Whether the application should be consistent with a relational database or NoSQL (perhaps both) is based, of course, on the nature of the data being generated or retrieved. Like most things in science and technology, it's a compromise to make a decision.
If scale and performance are more important than 24-hour data consistency, that NoSQL is an ideal choice (NoSQL relies on the base model-basic availability, soft state, final consistency).
But if you want to be consistent, especially with confidential information and financial information, MySQL is probably the best choice (MySQL relies on the acid model-atomicity, consistency, independence, and durability).
As open source databases, both relational and relational databases are maturing, and we can expect a slew of new applications based on the acid and base models.
For the moment it is called a hybrid scheme. Sometimes these applications are designed to weigh the pros and cons, sometimes develop unexpectedly, and make a series of adjustments to meet the changing needs of the data, after all, who can predict the massive increase in social sharing data today (even five years ago)?
As always, developers are at the forefront of this innovation, prompting managed service providers to combine these two data domains. They will also revise open source data technology when necessary.
For example, after Oracle has MySQL, MySQL has a closed source risk, based on MySQL mariadb a good alternative to MySQL. The developer community requires full transparency of its open source tools, including open access to test case bug fixes.
The hybrid scheme will continue to develop in 2014 and the hosting company will provide better support. In the media, we would not say "either relational or relational databases".
This is similar to the method used in the mixed cloud domain. Dedicated hardware has superior performance, and the public cloud has a good scalability, combining the advantages of the two can bring more flexibility to produce the most appropriate solution, which is the best solution to the problem.
After all, the ultimate goal of data collection and interpretation is to capture every piece of information that happens in this fast-changing world. Data, no matter where it comes from, is just a window, and what really matters is seeing through this window.