是否有新出现的 NoSQL 标准？
与大多数新技术一样，一段时间后就会出现标准。
有什么适合 NoSQL 的东西吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
与大多数新技术一样，一段时间后就会出现标准。
有什么适合 NoSQL 的东西吗？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（7）
NoSQL 的要点是没有标准的解决方案。每个数据存储问题都是不同的，您需要选择适合您的特定问题的数据存储技术，而不是“标准”技术。
这就是“Not Only SQL”的全部前提。
以 ACID 为例（这里有一条你从未想过会在 StackOverflow 上得到的建议，或者在 1987 年之后的任何地方得到的建议:-)）。有很多问题不需要 ACID 保证。对于这些问题，ACID 是多余的。过度杀伤会导致 I/O 浪费、CPU 周期浪费、性能浪费。这意味着浪费热量和能源，进而意味着浪费电费和公用事业费用。
有些问题只需要这些保证的较弱形式。例如，对于各种 Web 应用程序来说，所谓的最终一致性就足够了。其他问题需要比 SQL 样式 ACID 提供的更高保证。
因此，一些 NoSQL 数据库没有 ACID 保证，或者只有较弱的形式。有些可以根据每个数据库打开和关闭它们。有些可以在每个数据库的基础上单独打开和关闭A、C、I和D。有些不仅可以单独打开和关闭 A、C、I 和 D，还可以按滑动比例对其进行微调。有些甚至可以在每个查询的基础上执行此操作。
如果您有分层数据，请将其存储在分层数据库中。如果您有图形数据，请将其存储在图形数据库中。如果您有键值数据，请将其存储在键值数据库中。如果您有半结构化文档数据，请将其存储在文档数据库中。如果您有语义 RDF 数据，请将其存储在三元组数据库中。如果您构建数据仓库，请将其存储在列数据库中。如果您有关系数据，那么请务必将其存储在关系数据库中。 （但是仅如果您实际上有关系数据！）
The whole point of NoSQL is that there are no standard solutions. Every data storage problem is different, and you need to choose the data storage technology that is appropriate for your specific problem and not the one that is "the standard".
That's the whole premise of "Not Only SQL".
Take ACID (here's a pieve of advice you never thought you'd get on StackOverflow, or really anywhere after 1987 :-) ), for example. There is a wide array of problems which don't need ACID guarantees. For those problems, ACID is overkill. Overkill that translates into wasted I/O, wasted CPU cycles, wasted performance. Which means wasted heat and wasted energy, which in turn means wasted money on electrical and utility bills.
Some problems only need weaker forms of those guarantees. For example, for a wide array of web applications the so-called eventual consistency is plenty enough. Other problems need higher guarantees than what SQL-style ACID provides.
So, some NoSQL databases don't have ACID guarantees or only have them in a weaker form. Some can turn them on and off on a per-DB basis. Some can turn A, C, I and D on and off individually on a per-DB basis. Some can not only turn A, C, I and D on and off individually, they can finetune them on a sliding scale. Some can even do that on a per-query basis.
If you have hierarchical data, store it in a hierarchical database. If you have graph data, store it in a graph database. If you have key-value data, store it in a key-value database. If you have semi-structured document data, store it in a document database. If you have semantic RDF data, store it in a triple database. If you build a data warehouse, store it in a column database. And if you have relational data, then, by all means store it in a relational database. (But only if you actually have relational data!)
正如 Jörg 所解释的 (+1)，不存在单一标准的 NoSQL 解决方案。 NoSQL 一词涵盖了广泛的数据库类型，每种类型都针对特定的数据领域量身定制。
Ayende 的 That No SQL Thing 系列介绍了一些主流的 NoSQL 解决方案，并重点介绍了每种类型的优点和缺点。他讨论了以下内容：
您可以将这些不同类型视为 NoSQL 中的标准。请记住，它们中的每一个都专门用于解决某些数据存储问题。不存在“一刀切”的解决方案：所有这些都将继续存在。
There is no single standard NoSQL solution, as Jörg explained (+1). The term NoSQL covers a wide array of database types, each tailored for a specific data domain.
Ayende's That No SQL Thing series takes a look at some of the mainstream NoSQL solutions and highlights the strengths and weaknesses of each type. He discusses the following:
You can think of these different types as standards within NoSQL. Just remember that each of them is specialized for certain data storage problems. There's no "one size fits all" solution: all of them will continue to exist.
正在开发一种名为 UnQL 的 JSON、半结构化和文档数据库查询语言：
http://www .unqlspec.org/display/UnQL/Home
A query language for JSON, semi-structured and document databases called UnQL is being developed:
http://www.unqlspec.org/display/UnQL/Home
有些人考虑过文档数据库的标准： http:// nosql.mypopescu.com/post/731261002/a-common-nosql-query-language。
然而，键值存储和文档数据库不进行连接，这意味着它们的查询语言简单且易于学习。对 SQL 这样的通用语言的需求较少。
然而.NET开发人员可以使用LINQ来访问文档数据库的MongoDB和RavenDB，并且有些人正在开发一个LINQ提供程序来文档数据库CouchDB： http://github.com/sinesignal/ottoman 。 LINQ 不是 NoSQL 标准，而是与数据相关的所有内容的标准。您也可以使用它与关系数据库或 xml 文件进行交互。
图形数据库与键值存储和文档数据库有很大不同。我认为你无法将它们统一为一个标准。我真的不知道是否可以为图形数据库开发 LINQ 提供程序。我想不是，但我不确定。
Some people have contemplated about standards for document db's: http://nosql.mypopescu.com/post/731261002/a-common-nosql-query-language .
However key-value-stores and document db's don't do joins and that means that their query languages are simple and easy to learn. There is less need for a common language like SQL.
However .NET developers can use LINQ to access document db's MongoDB and RavenDB, and some people are developing a LINQ provider to document db CouchDB: http://github.com/sinesignal/ottoman . LINQ isn't a NoSQL standard but a standard for everything that is related to data. You can use it to talk to a relational database or an xml file too.
Graph databases are very different from key-value-stores and document db's. I don't think you can unite them in one standard. I really don't know if it is possible to develop a LINQ provider for a graph database. I guess not but I'm not sure.
某些 NoSQL 产品支持 SQL 或其超集。 OrientDB 就是这种情况，它是一个支持 SQL 的文档图 nosql 数据库管理系统。它是根据 Apache 2 许可证发布的。
此外，它还可以以 JSON 格式导出文档（您可以以 JSON 格式导出/导入整个数据库）。其他 NoSQL 产品读/写 JSON。
再见，
LV@
Some NoSQL product supports SQL or a super set of it. This is the case of OrientDB, a document-graph nosql dbms with the support of SQL. It's released under Apache 2 license.
Furthermore it can export document in JSON format (you can export/import the entire database in JSON). Other NoSQL products read/write JSON.
bye,
Lvc@
（专门针对称为文档数据库的 NoSQL 子集）。
许多文档数据库不公开“查询语言”。相反，他们通常提供查询 API，并且这些 API 特定于实现并由实现的各个发起者/所有者控制（例如 MongoDB 的 10gen）。
在 XML 数据库空间（文档数据库的子集）中，有 W3C 标准 XQuery。它是一种查询和函数式编程语言，设计用于查询 XML 数据集合（维基百科称）。
目前尚不清楚是否需要/渴望 JSON 数据的标准查询 API（或语言）。 JSONPath （类似于 XPath) 已被提出，但除了
(Speaking specifically on subset of NoSQL known as Document databases).
Many document databases do not expose a "Query Language". In lieu, they often provide Query APIs and these APIs are specific to the implementation and controlled by the individual sponsors/owners of the implementations (10gen for MongoDB, for example).
In the XML database space (a subset of Document databases), there is the W3C standard XQuery. It is a query and functional programming language designed for querying collections of XML data (says wikipedia).
It is unclear yet if there is any need/desire for a standard query API (or language) for JSON data. JSONPath (analogous to XPath) has been proposed, but it's received little attention other than it's use by Kynetx .
一个可能有趣的应用是 AppScale，它为 HBase、Hypertable、MySQL Cluster、Cassandra、Voldemort、MongoDB 提供了统一的 API 、MemcacheDB 和 Redis。该 API 由 Google 为 Google App Engine 定义，可用于 Java 、Python 和 前往。
One potentially interesting one is AppScale which provides a unified API for HBase, Hypertable, MySQL Cluster, Cassandra, Voldemort, MongoDB, MemcacheDB and Redis. The API is defined by Google for the Google App Engine and is available for Java, Python and Go.