Non-Relational (NoRel) là gì, kiến trúc, phân loại?

I . NoSQL là gì?

1. Thuật ngữ

NoSQL còn có nghĩa là Non-Relational (NoRel) - không ràng buộc. Tuy nhiên, thuật ngữ đó ít phổ dụng hơn và ngày nay người ta thường dịch NoSQL thành Not Only SQL - Không chỉ SQL. NoSQL ám chỉ đến những cơ sở dữ liệu không dùng mô hình dữ liệu quan hệ để quản lý dữ liệu trong lĩnh vực phần mềm.

2. Lịch sử

Thuật ngữ NoSQL được giới thiệu lần đầu vào năm 1998 sử dụng làm tên gọi chung cho các lightweight open source relational database (cơ sở dữ liệu quan hệ nguồn mở nhỏ) nhưng không sử dụng SQL cho truy vấn. Vào năm 2009, Eric Evans, nhân viên của Rackspace giới thiệu lại thuật ngữ NoSQL trong một hội thảo về cơ sở dữ liệu nguồn mở phân tán. Thuật ngữ NoSQL đánh dấu bước phát triển của
thế hệ database mới: distributed (phân tán) + non-relational (không ràng buộc).

Ghi chú: Một mệnh đề khá thú vị về non-relational data store: "select fun, profit from real_world where relational=false;".

3. Định nghĩa

Thế hệ database kế tiếp là một thế hệ cơ sở dữ liệu non-relational (không ràng buộc), distributed (phân tán), open source, horizontal scalable (khả năng mở rộng theo chiều ngang) có thể lưu trữ, xử lý từ một lượng rất nhỏ cho tới hàng petabytes dữ liệu trong hệ thống có độ chịu tải, lỗi cao với những đòi hỏi về tài nguyên phần cứng thấp. Một số đặc điểm nhận dạng cho thế hệ database mới này bao gồm: schema-free, hỗ trợ mở rộng dễ dàng, API đơn giản, eventual consistency (nhất quán cuối) và/hoặc transactions hạn chế trên
các thành phần dữ liệu đơn lẻ, không giới hạn không gian dữ liệu,... NoSQL storage đặc biệt phổ dụng trong thời kỳ Web 2.0 bùng nổ, nơi các mạng dịch vụ dữ liệu cộng đồng cho phép người dùng tạo hàng tỷ nội dung trên web. Do đó, dữ liệu lớn rất nhanh vượt qua giới hạn phần cứng và cần phải giải quyết bằng bài toán phân tán. Nửa đầu năm 2009, người ta đã manh nha thuật ngữ NoSQL đánh dấu sự trưởng thành của thế hệ database mới trong khi những sản phẩm phần mềm có thể đã được phát triển từ trước đó rất lâu.

4. Một số thuật ngữ liên quan.

 - non-relational: relational - ràng buộc - thuật ngữ sử dụng đến các mối quan hệ giữa các bảng trong cơ sở dữ liệu quan hệ (RDBMs) sử dụng mô hình khóa gồm 2 loại khóa: khóa chính và khóa phụ (primary key + foreign key) để ràng buộc dữ liệu nhằm thể hiện tính nhất quán dữ liệu từ các bảng khác nhau. Non-relational là khái niệm không sử dụng các ràng buộc dữ liệu cho nhất quán dữ liệu ở NoSQL database.

 - distributed storage: mô hình lưu trữ phân tán các file hoặc dữ liệu ra nhiều máy tính khác nhau trong mạng LAN hoặc Internet dưới sự kiểm soát của phần mềm.

- eventual consistency (nhất quán cuối): tính nhất quán của dữ liệu không cần phải đảm bảo ngay tức khắc sau mỗi phép write. Một hệ thống phân tán chấp nhận những ảnh hưởng theo phương thức lan truyền và sau một khoảng thời gian (không phải ngay tức khắc), thay đổi sẽ đi đến mọi điểm trong hệ thống, tức là cuối cùng (eventually) dữ liệu trên hệ thống sẽ trở lại trạng
thái nhất quán.

 - vertical scalable (khả năng mở rộng chiều dọc): Khi dữ liệu lớn về lượng, phương pháp tăng cường khả năng lưu trữ và xử lý bằng việc cải tiến phần mềm và cải thiện phần cứng trên một máy tính đơn lẻ được gọi là khả năng mở rộng chiều dọc. Ví dụ việc tăng cường CPUs, cải thiện đĩa cứng, bộ nhớ trong một máy tính,... cho DBMs nằm trong phạm trù này. Khả năng mở rộng chiều dọc còn có một thuật ngữ khác scale up.

 - horizontal scalable (khả năng mở rộng chiều ngang): Khi dữ liệu lớn về lượng, phương pháp tăng cường khả năng lưu trữ và xử lý là dùng nhiều máy tính phân tán. Phân tán dữ liệu được hỗ trợ bởi phần mềm tức cơ sở dữ liệu. Trong khi giá thành phần cứng ngày càng giảm, tốc độ xử lý, bộ nhớ ngày càng tăng thì horizontal scalable là một lựa chọn đúng đắn. Hàng trăm máy tính nhỏ được chập lại tạo thành một hệ thống tính toán mạnh hơn nhiều so với vi xử lý RISC truyền thống đơn lẻ. Mô hình này tiếp tục được hỗ trợ bởi các công nghệ kết nối Myrinet và InfiniBand. Từ đó chúng ta có thể quản lý, bảo trì từ xa, xây dựng batch procession (xử lý đồng loạt tập lệnh) tốt hơn. Do những đòi hỏi về tốc độ xử lý I/O cao, lượng cực lớn dữ liệu,... scale horizontally sẽ thúc đẩy các công nghệ lưu trữ mới phát triển giống như object storage devices (OSD)

II. Kiến trúc

1. Sơ lược.

Các RDBMs hiện tại đã bộc lộ những yếu kém như việc đánh chỉ mục một lượng lớn dữ liệu, phân trang, hoặc phân phối luồng dữ liệu media (phim, ảnh, nhạc, ...). Cơ sở dữ liệu quan hệ được thiết kế cho những mô hình dữ liệu nhỏ thường xuyên đọc viết trong khi các Social Network Services lại có một lượng dữ liệu cực lớn và cập nhật liên tục do số lượng người dùng quá nhiều ở một thời điểm. Thiết kế trên Distributed NoSQL giảm thiểu tối đa các phép tính toán, I/O liên quan kết hợp với batch processing đủ đảm bảo được yêu cầu xử lý dữ liệu của các mạng dịch vụ dữ liệu cộng đồng này. Facebook, Amazon là những ví dụ điểm hình. Về cơ bản, các thiết kế của NoSQL lựa chọn mô hình lưu trữ tập dữ liệu theo cặp giá trị keyvalue. Khái niệm node được sử dụng trong quản lý dữ liệu phân tán. Với các hệ thống phân tán, việc lưu trữ có chấp nhận trùng lặp dữ liệu. Một request truy vấn tới data có thể gửi tới nhiều máy cùng lúc, khi một máy nào nó bị chết cũng không ảnh hưởng nhiều tới toàn bộ hệ thống. Để đảm bảo tính real time trong các hệ thống xử lý lượng lớn, thông thường người ta sẽ tách biệt database ra làm 2 hoặc nhiều database. Một database nhỏ đảm bảo vào ra liên tục, khi đạt tới ngưỡng thời gian hoặc dung lượng, database nhỏ sẽ được gộp (merge) vào database lớn có thiết kế tối ưu cho phép đọc (read operation). Mô hình đó cho phép tăng cường hiệu suất I/O - một trong những nguyên nhân chính khiến performance trở nên kém.

2. Một số đặc điểm.

- High Scalability: Gần như không có một giới hạn cho dữ liệu và người dùng trên hệ thống.

- High Availability: Do chấp nhận sự trùng lặp trong lưu trữ nên nếu một node (commodity machine) nào đó bị chết cũng không ảnh hưởng tới toàn bộ hệ thống.

- Atomicity: Độc lập data state trong các operation.

- Consistency: chấp nhận tính nhất quán yếu, cập nhật mới không đảm bảo rằng các truy xuất sau đó thấy ngay được sự thay đổi. Sau một khoảng thời gian lan truyền thì tính nhất quán cuối cùng của dữ liệu mới được đảm bảo.

- Durability: dữ liệu có thể tồn tại trong bộ nhớ máy tính nhưng đồng thời cũng được lưu trữ lại đĩa cứng.

- Deployment Flexibility: việc bổ sung thêm/loại bỏ các node, hệ thống sẽ tự động nhận biết để lưu trữ mà không cần phải can thiệp bằng tay. Hệ thống cũng không đòi hỏi cấu hình phần cứng mạnh, đồng nhất.

- Modeling flexibility: Key-Value pairs, Hierarchical data (dữ liệu cấu trúc), Graphs.

- Query Flexibility: Multi-Gets, Range queries (load một tập giá trị dựa vào một dãy các khóa).

3. What is NoSQL (technically speaking)?

Đừng gọi chúng là database. CTO của Amazon, Werner Vogels đề cập đến hệ thống Dynamo của họ đã gọi nó là một "highly available key-value store". Google gọi BigTable để nhấn mạnh đây là "distributed storage system for managing structured data" (hệ thống lưu trữ và quản lý dữ liệu cấu trúc có phân tán).

Có thể thổi bay một lượng dữ liệu cực lớn. Hypertable, một open source column-based database trên mô hình BigTable được sử dụng cho local search engine của Zvents Inc có thể ghi tới 1 tỷ cell dữ liệu mỗi ngày (theo Doug Judd một kỹ sư của Zvents). Trong khi đó BigTable kết hợp với MapReduce có thể xử lý tới 20 petabytes dữ liệu mỗi ngày. Đánh bại performance bottlenecks. Bằng việc bỏ qua thông dịch trong SQL cùng với những truy vấn rườm rà, NoSQL cho ta một kiến trúc tối ưu về tốc độ thực thi (ghi và truy vấn dữ liệu)

Việc sử dụng các ràng buộc quan hệ cùng truy vấn SQL có vẻ thân thiện và thích hợp với phần đông dữ liệu. Tuy nhiên, nếu dữ liệu quá đơn giản, các thủ tục SQL sẽ không cần thiết (theo Curt Monash - một nhà phân tích cơ sở dữ liệu, một blogger). Raffaele Sena, một senior computer scientist ở Adobe Systems Inc. đã nói rằng ConnectNow Web collaboration service của họ sử dụng Java clustering software từ Terracotta thay cho cơ sở dữ liệu quan hệ đã khiến "hệ thống của họ trở nên mạnh hơn, phức tạp hơn so với việc sử dụng
cơ sở dữ liệu quan hệ".

Các thiết kế database có tính đặc thù (như document-oriented database) sẽ lược bỏ được tầng chuyển đổi sang mô hình lưu trữ quan hệ từ interface của nó đồng thời khiến giao tiếp tương tác trở nên tự nhiên hơn.

Không quá cần thiết. Đồng ý rằng RDBMs cung cấp một mô hình tuyệt vời để đảm bảo tính toàn vẹn dữ liệu. Tuy nhiên, rất nhiều người lựa chọn NoSQL đã nói rằng chúng không quá cần thiết cho nhu cầu của họ. Như trong dự án ConnectNow của Adobe, dữ liệu người dùng trong một session không cần thiết phải lưu lại, chúng sẽ bị xóa khi người dùng logoff. Vì vậy, một keyvalue memory storage là đủ dùng.

III. Phân loại

A. Core NoSQL Systems

1. Wide Column Store / Column Families

Hệ cơ sở dữ liệu phân tán cho phép truy xuất ngẫu nhiên/tức thời với khả năng lưu trữ một lượng cực lớn data có cấu trúc. Dữ liệu có thể tồn tại dạng bảng với hàng tỷ bản ghi và mỗi bản ghi có thể chứa hàng triệu cột. Một triển khai từ vài trăm cho tới hàng nghìn commodity hardware dẫn đến khả năng lưu trữ hàng petabytes nhưng vẫn đảm bảo high performance. Dưới đây là một số sản  phẩm  thông  dụng:   Hadoop/HBase  –  Apache,  BigTable  –  Google,  Cassandra  -Facebook/Apache, Hypertable - Zvents Inc/Baidu, Cloudera, SciDB, Mnesia, Tablets,…

2. Key-Value Store/Tuple store

Mô hình lưu trữ dữ liệu dưới cặp giá trị key-value trong đó việc truy xuất, xóa, cập nhật giá trị thực thông qua key tương ứng. Với sự bổ trợ bởi các kỹ thuật BTree, B+Tree, Hash,... dữ liệu có thể tồn tại trên RAM hoặc đĩa cứng, phân tán hoặc không phân tán.  Hầu hết các NoSQL
database đều là key-value store. Dưới đây là một số đặc tính có thể được hỗ trợ trong sản phẩm dạng này:

a. Key/value cache in RAM:  memcached, Citrusleaf database, Velocity, Redis, Tuple space,...

b. Key/value save on disk: Memcachedb, Berkeley DB, Tokyo Cabinet, Redis,...

c. Eventually Consistent Key Value Store:  Amazon Dynamo, Voldemort, Dynomite, KAI, Cassandra, Hibari, Project Voldemort,…

d. Ordered key-value store: NMDB, Memcachedb, Berkeley DB,...

e. Distributed systems:  Apache River , MEMBASE,  Azure Table Storage,  Amazon Dynamo,... Ghi chú: Tuple Store: schema free, an ordered list of elements.

3. Document Store

Thực chất là các document-oriented database - một thiết kế riêng biệt cho việc lưu trữ document. Các cài đặt có thể là giả lập tương tác trên relational database, object database hay key-value store. Một số sản phẩm tiêu biểu: Apache Jackrabbit, CouchDB, IBM Lotus Notes Storage Format (NSF),MongoDB, Terrastore, ThruDB, OrientDB, RavenDB,...

4. Graph Database

Graph database là một dạng cơ sở dữ liệu được thiết kế riêng cho việc lưu trữ thông tin đồ họa như cạnh, nút, properties. Một số sản phẩm tiêu biểu: Neo4J, Sones, AllegroGraph, Core Data, DEX, FlockDB, InfoGrid, OpenLink Virtuoso,...

B. Soft NoSQL Systems

1. Object Databases: db4o, GemStone/S, InterSystems Caché, JADE, JOOB, Objectivity/DB, ZODB, Versant, Objectivity, NEO,...

2. XML Databases: Mark Logic Server, EMC Documentum xDB, eXist, Sedna, Berkeley DB XML, ...

3. Multivalue Databases: U2, OpenInsight,OpenQM

4. Grid Database Solutions: GigaSpaces, Hazelcast, GridGain, Infinispan, Coherence, ...

5. other NoSQL related databases: IBM Lotus/Domino, ISIS Family, Prevayler, eXtremeScal,...

V. Tài liệu tham khảo và lược dịch

1. NoSQL resources: http://nosql-database.org/
2. NoSQL wiki - http://en.wikipedia.org/wiki/NoSQL
3. Scalability wiki - http://en.wikipedia.org/wiki/Scalability#Scale_horizontally_.28scale_out.29
4.No to SQL? Anti-database movement gains steam -http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_?taxonomyId=173&pageNumber=1
5. MongoDB vs. SQL Server 2008 Performance Showdown -http://www.michaelckennedy.net/blog/2010/04/29/MongoDBVsSQLServer2008PerformanceShowdown.aspx
6. A Brief History of NoSQL - http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.html
7. NoSql Databases – Part 1 - Landscape - http://www.vineetgupta.com/2010/01/nosqldatabases-part-1-landscape.html
8. Nhất Quán Cuối Cùng - http://www.sqlviet.com/blog/nhat-quan-cuoi-cung
9. NoSQL in the Enterprise - http://www.infoq.com/articles/nosql-in-the-enterprise

Nhữ Đình Thuận

Voldemort là một chìa khóa có giá trị lưu trữ hệ thống phân phối

    * Dữ liệu được tự động sao chép trên nhiều máy chủ.
    * Dữ liệu được tự động phân vùng vì vậy mỗi máy chủ có chứa chỉ một tập hợp các dữ liệu tổng
    * Server không được xử lý minh bạch
    * Pluggable tuần tự được hỗ trợ để cho phép các phím phong phú và giá trị bao gồm danh sách và dữ liệu với các lĩnh vực được đặt tên, cũng như để tích hợp với các khuôn khổ tuần tự thông thường như Nghị định thư đệm, tiết kiệm, và Java Serialization
    * Mục dữ liệu được là phiên bản để tối đa hóa toàn vẹn dữ liệu trong các kịch bản thất bại mà không ảnh hưởng sẵn có của hệ thống
    * Mỗi nút là độc lập với các nút khác không có điểm trung tâm của sự thất bại hoặc phối hợp
    * Hiệu suất tốt nút duy nhất: bạn có thể mong đợi hoạt động 10-20k / giây tùy thuộc vào máy móc, mạng lưới, hệ thống đĩa, và sao chép dữ liệu các yếu tố
    * Hỗ trợ cho các chiến lược theo vị trí cắm dữ liệu để hỗ trợ những thứ như phân phối qua trung tâm dữ liệu có địa lý cách xa nhau.

Nó được sử dụng tại LinkedIn cho các vấn đề lưu trữ nhất định cao khả năng mở rộng hợp phân vùng chức năng đơn giản là không đủ. Nó vẫn là một hệ thống mới có cạnh thô, thông báo lỗi xấu, và có lẽ rất nhiều lỗi còn tự do. Cho chúng tôi biết nếu bạn tìm thấy một trong số này, vì vậy chúng tôi có thể sửa chữa nó.

So sánh với cơ sở dữ liệu quan hệ

Voldemort không phải là một cơ sở dữ liệu quan hệ, nó không cố gắng để đáp ứng các mối quan hệ độc đoán trong khi đáp ứng các đặc tính ACID. Cũng không phải là một cơ sở dữ liệu đối tượng mà nỗ lực để minh bạch các đồ thị bản đồ tham chiếu đối tượng. Cũng không giới thiệu một trừu tượng mới như định hướng, tài liệu. Đó là về cơ bản chỉ là một, phân phối lớn, kéo dài, bảng băm chịu lỗi. Đối với các ứng dụng có thể sử dụng một O / R mapper như ActiveRecord hoặc Hibernate này sẽ cung cấp khả năng mở rộng theo chiều ngang và sẵn sàng cao hơn nhiều nhưng mất mát lớn lao của sự thuận tiện. Đối với các ứng dụng lớn dưới áp lực kiểu khả năng mở rộng internet, một hệ thống có khả năng có thể bao gồm một số dịch vụ chức năng phân chia hoặc apis, có thể quản lý tài nguyên lưu trữ trên nhiều trung tâm dữ liệu sử dụng hệ thống lưu trữ mà mình có thể được phân chia theo chiều ngang. Đối với các ứng dụng trong không gian này, tùy tiện trong cơ sở dữ liệu đã không thể tham gia kể từ khi tất cả các dữ liệu không có trong bất kỳ cơ sở dữ liệu duy nhất. Một mô hình điển hình là giới thiệu một lớp đệm này sẽ đòi hỏi ngữ nghĩa Hashtable anyway. Đối với các ứng dụng này Voldemort cung cấp một số lợi thế:

    * Voldemort kết hợp trong bộ nhớ đệm bộ nhớ với hệ thống lưu trữ để có một bộ nhớ đệm riêng biệt cấp là không cần thiết (thay vì hệ thống lưu trữ chính nó là chỉ cần nhanh).
    * Không giống như MySQL nhân rộng, cả đọc và viết quy mô theo chiều ngang
    * Dữ liệu partioning là minh bạch, và cho phép mở rộng cụm mà không tái cân bằng tất cả dữ liệu
    * Sao chép dữ liệu và vị trí được quyết định bởi một API đơn giản để có thể đáp ứng một loạt các ứng dụng cụ thể chiến lược
    * Các lớp lưu trữ là hoàn toàn mockable để phát triển và kiểm tra đơn vị có thể được thực hiện đối với một hệ thống-đi ném lưu trữ trong bộ nhớ mà không cần một cụm sản (hoặc ngay cả một hệ thống lưu trữ thực) để thử nghiệm đơn giản

Alternative Data Storages

• [n1] Memcached: a distributed memory object caching system

• [n2] CouchDB partitioning and replication: according to a 2009 Summer of code proposal: While distributed deployments have been achieved with the help of proxies and smart external scripting, the core of CouchDB itself does not currently support distributing the database across multiple machines. More references about CouchDB cluster:

  • CouchDB Cluster

  • couchdb-lounge: Clustering framework for CouchDB

• [n3] All other criteria for CloudBase have been deduced based on the HDFS/Hadoop capabilities

• [n4] Cassandra: Consistent hashing vs order-preserving partitioning in distributed databases

• [n5] LightCloud seems to be a set of management scripts (Python) for Tokyo Tyrant

Implementation details

Performance

I usually do not trust micro-benchmarks. I know that performance measuring is an art. But I also know that some are looking for this sort of data and sometimes even the smallest piece of information is more helpful than nothing.

Other projects

I have found a couple of other projects, but I couldn’t decide if they fit in or not. In case you consider that I should include them please do let me know (a helpful argument is also highly appreciated)

• Neo4j

• Schemafree

• Vertica

• Virtuoso

I’d like to also mention the FriendFeed usage of MySQL, which while not being a new system in itself it was conceived to behave like a BASE .

 

Five advantages of NoSQL

1: Elastic scaling

For years, database administrators have relied on scale up — buying bigger servers as database load increases — rather than scale out — distributing the database across multiple hosts as load increases. However, as transaction rates and availability requirements increase, and as databases move into the cloud or onto virtualized environments, the economic advantages of scaling out on commodity hardware become irresistible.

RDBMS might not scale out easily on commodity clusters, but the new breed of NoSQL databases are designed to expand transparently to take advantage of new nodes, and they’re usually designed with low-cost commodity hardware in mind.

2: Big data

Just as transaction rates have grown out of recognition over the last decade, the volumes of data that are being stored also have increased massively. O’Reilly has cleverly called this the “industrial revolution of data.” RDBMS capacity has been growing to match these increases, but as with transaction rates, the constraints of data volumes that can be practically managed by a single RDBMS are becoming intolerable for some enterprises. Today, the volumes of “big data” that can be handled by NoSQL systems, such as Hadoop, outstrip what can be handled by the biggest RDBMS.

3: Goodbye DBAs (see you later?)

Despite the many manageability improvements claimed by RDBMS vendors over the years, high-end RDBMS systems can be maintained only with the assistance of expensive, highly trained DBAs. DBAs are intimately involved in the design, installation, and ongoing tuning of high-end RDBMS systems.

NoSQL databases are generally designed from the ground up to require less management:  automatic repair, data distribution, and simpler data models lead to lower administration and tuning requirements — in theory. In practice, it’s likely that rumors of the DBA’s death have been slightly exaggerated. Someone will always be accountable for the performance and availability of any mission-critical data store.

4: Economics

NoSQL databases typically use clusters of cheap commodity servers to manage the exploding data and transaction volumes, while RDBMS tends to rely on expensive proprietary servers and storage systems. The result is that the cost per gigabyte or transaction/second for NoSQL can be many times less than the cost for RDBMS, allowing you to store and process more data at a much lower price point.

5: Flexible data models

Change management is a big headache for large production RDBMS. Even minor changes to the data model of an RDBMS have to be carefully managed and may necessitate downtime or reduced service levels.

NoSQL databases have far more relaxed — or even nonexistent — data model restrictions. NoSQL Key Value stores and document databases allow the application to store virtually any structure it wants in a data element. Even the more rigidly defined BigTable-based NoSQL databases (Cassandra, HBase) typically allow new columns to be created without too much fuss.

The result is that application changes and database schema changes do not have to be managed as one complicated change unit. In theory, this will allow applications to iterate faster, though,clearly, there can be undesirable side effects if the application fails to manage data integrity.

Five challenges of NoSQL

The promise of the NoSQL database has generated a lot of enthusiasm, but there are many obstacles to overcome before they can appeal to mainstream enterprises. Here are a few of the top challenges.

1: Maturity

RDBMS systems have been around for a long time. NoSQL advocates will argue that their advancing age is a sign of their obsolescence, but for most CIOs, the maturity of the RDBMS is reassuring. For the most part, RDBMS systems are stable and richly functional. In comparison, most NoSQL alternatives are in pre-production versions with many key features yet to be implemented.

Living on the technological leading edge is an exciting prospect for many developers, but enterprises should approach it with extreme caution.

2: Support

Enterprises want the reassurance that if a key system fails, they will be able to get timely and competent support. All RDBMS vendors go to great lengths to provide a high level of enterprise support.

In contrast, most NoSQL systems are open source projects, and although there are usually one or more firms offering support for each NoSQL database, these companies often are small start-ups without the global reach, support resources, or credibility of an Oracle, Microsoft, or IBM.

3: Analytics and business intelligence

NoSQL databases have evolved to meet the scaling demands of modern Web 2.0 applications. Consequently, most of their feature set is oriented toward the demands of these applications. However, data in an application has value to the business that goes beyond the insert-read-update-delete cycle of a typical Web application. Businesses mine information in corporate databases to improve their efficiency and competitiveness, and business intelligence (BI) is a key IT issue for all medium to large companies.

NoSQL databases offer few facilities for ad-hoc query and analysis. Even a simple query requires significant programming expertise, and commonly used BI tools do not provide connectivity to NoSQL.

Some relief is provided by the emergence of solutions such as HIVE or PIG, which can provide easier access to data held in Hadoop clusters and perhaps eventually, other NoSQL databases. Quest Software has developed a product — Toad for Cloud Databases — that can provide ad-hoc query capabilities to a variety of NoSQL databases.

4: Administration

The design goals for NoSQL may be to provide a zero-admin solution, but the current reality falls well short of that goal. NoSQL today requires a lot of skill to install and a lot of effort to maintain.

5: Expertise

There are literally millions of developers throughout the world, and in every business segment, who are familiar with RDBMS concepts and programming. In contrast, almost every NoSQL developer is in a learning mode. This situation will address naturally over time, but for now, it’s far easier to find experienced RDBMS programmers or administrators than a NoSQL expert.

Conclusion

NoSQL databases are becoming an increasingly important part of the database landscape, and when used appropriately, can offer real benefits. However, enterprises should proceed with caution with full awareness of the legitimate limitations and issues that are associated with these databases.