您能否指出替代数据存储工具并给出使用它们而不是旧的关系数据库的充分理由？在我看来，大多数应用程序很少使用 SQL 的全部功能——看看如何构建一个无 SQL 的应用程序会很有趣。
caustic
问问题
21190 次
21 回答
148
文件系统中的纯文本文件
- 创建和编辑非常简单
- 用户可以使用简单的工具（即文本编辑器、grep 等）轻松操作
- 高效存储二进制文档
磁盘上的 XML 或 JSON 文件
- 如上所述，但具有更多验证结构的能力。
电子表格/CSV 文件
- 商业用户非常容易理解的模型
Subversion（或类似的基于磁盘的版本控制系统）
- 非常好地支持数据的版本控制
Berkeley DB（基本上，基于磁盘的哈希表）
- 概念上非常简单（只是未键入的键/值）
- 蛮快
- 没有管理开销
- 支持我相信的交易
- 我相信很像伯克利 DB，但托管
- 托管且高度可扩展
- 按文档键值存储（即灵活的数据模型）
- 文档重点
- 半结构化/基于文档的数据的简单存储
本机语言集合（存储在内存中或在磁盘上序列化）
- 非常紧密的语言集成
自定义（手写）存储引擎
- 在所需用例中可能具有非常高的性能
我不能声称对它们了解太多，但您可能还想研究对象数据库系统。
于 2008-09-01T12:19:14.193 回答
26
Matt Sheppard 的回答很棒（修改），但在考虑主轴时我会考虑这些因素：
- 结构：它是否明显分解成碎片，或者您是否在进行权衡？
- 用法：如何分析/检索/挖掘数据？
- 生命周期：数据有用多长时间？
- 大小：有多少数据？
CSV 文件相对于 RDBMS 的一个特殊优势是它们可以很容易地压缩并移动到几乎任何其他机器上。我们进行大数据传输，一切都很简单，我们只使用一个大的 CSV 文件，并且使用 rsync 等工具轻松编写脚本。为了减少大型 CSV 文件的重复，您可以使用YAML 之类的东西。我不确定我会存储 JSON 或 XML 之类的任何内容，除非您有重要的关系要求。
至于未提及的替代方案，请不要低估Hadoop，它是 MapReduce 的开源实现。如果您有大量结构松散的数据需要分析，并且您希望处于一个只需添加 10 台机器来处理数据处理的场景中，这应该会很有效。
例如，我开始尝试分析性能，它基本上是在大约 20 台机器上记录的不同功能的所有计时数。在尝试将所有内容都粘贴到 RDBMS 中之后，我意识到一旦聚合数据，我真的不需要再次查询数据。而且，它只对我有用的是它的聚合格式。所以，我保留日志文件，压缩，然后将聚合数据留在数据库中。
注意我更习惯于思考“大”尺寸。
于 2008-09-01T14:33:03.170 回答
10
文件系统在存储二进制数据方面非常方便，而在关系数据库中这种数据从来都不是很好。
于 2008-09-01T12:14:38.620 回答
6
试试 Prevayler： http: //www.prevayler.org/wiki/ Prevayler 是 RDBMS 的替代品。在网站上有更多信息。
于 2008-09-01T12:20:55.063 回答
6
自定义（手写）存储引擎/在所需用例中可能具有非常高的性能
如果您有大量数据集，而不是自己滚动，您可能会使用 HDF，即分层数据格式。
http://en.wikipedia.org/wiki/Hierarchical_Data_Format：
HDF 支持多种不同的数据模型，包括多维数组、光栅图像和表格。
它也像文件系统一样是分层的，但数据存储在一个神奇的二进制文件中。
HDF5 是一个套件，可以管理极其庞大和复杂的数据集合。
想想 PB 级的 NASA/JPL 遥感数据。
于 2008-09-05T22:22:54.190 回答
6
如果您不需要ACID，则可能不需要 RDBMS 的开销。所以，首先确定你是否需要它。此处提供的大多数非 RDBMS 答案不提供 ACID。
于 2008-09-28T10:22:27.550 回答
4
天，
我能想到的一种情况是，当您正在建模的数据无法在关系数据库中轻松表示时。
例如，移动电话运营商使用的数据库来监控和控制移动电话网络的基站。
我几乎在所有这些情况下都使用了OO DB，无论是商业产品还是允许对象层次结构的自滚动系统。
我为一家大公司开发了一个 3G 监控应用程序，该公司将保持无名，但其徽标是红酒渍（-: ，他们使用这样的 OO DB 来跟踪单个单元格内的所有各种属性网络。
对此类 DB 的查询是使用通常完全不受 SQL 影响的专有技术完成的。
HTH。
干杯，
抢
于 2008-09-01T12:16:40.237 回答
3
对象数据库不是关系数据库。如果您只想将一些对象填充到数据库中，它们会非常方便。它们还支持版本控制和修改数据库中已存在的对象的类。db4o是第一个想到的。
于 2008-09-01T12:20:28.387 回答
3
在某些情况下（例如金融市场数据和流程控制），您可能需要使用实时数据库而不是 RDBMS。见维基链接
于 2008-09-01T15:21:12.960 回答
3
几年前编写了一个名为JADE的 RAD 工具，它具有内置的 OODBMS。DB 引擎的早期版本也支持 Digitalk Smalltalk。如果您想使用非 RDBMS 范例构建应用程序示例，这可能是一个开始。
其他 OODBMS 产品包括Objectivity、GemStone（您需要获得VisualWorks Smalltalk 才能运行 Smalltalk 版本，但也有 java 版本）。在这个领域也有一些开源研究项目——我想到了 EXODUS 及其后代 SHORE。
可悲的是，这个概念似乎死了，可能是由于缺乏清晰可见的标准和相对于基于 SQL 的 RDMBS 系统相对较差的临时查询能力。
OODBMS 最适合具有核心数据结构的应用程序，这些数据结构最好表示为互连节点的图。我曾经说过，典型的 OODBMS 应用程序是一个多用户地牢 (MUD)，其中房间将包含玩家的化身和其他对象。
于 2008-09-18T20:49:57.817 回答
1
仅使用存储在文件系统中的文件，您就可以走很长一段路。RDBMS 在处理 blob 方面越来越好，但这可能是处理图像数据等的一种自然方式，尤其是在查询很简单的情况下（枚举和选择单个项目）。
其他不太适合 RDBMS 的东西是分层数据结构，我猜地理空间数据和 3D 模型也不是那么容易使用。
Amazon S3等服务提供不支持 SQL 的更简单的存储模型（键->值）。可扩展性是那里的关键。
Excel 文件也很有用，特别是如果用户需要能够在熟悉的环境中操作数据并且构建完整的应用程序来做到这一点是不可行的。
于 2008-09-01T12:20:52.707 回答
1
存储数据的方法有很多种——甚至“关系数据库”也涵盖了一系列替代方案，从一个简单的代码库，它可以像在单个用户基础上操作一个（或多个文件）的关系数据库一样，通过基于文件的系统比可以处理多用户到大量严肃的基于“服务器”的系统。
我们经常使用 XML 文件——您可以获得结构良好的数据、用于查询的好工具以及在适当情况下进行编辑的能力、人类可读的东西，您不必担心数据库引擎的工作（或数据库引擎）。这适用于本质上只读的东西（在我们的例子中，通常是从其他地方的数据库生成的）以及单用户系统，您可以在其中加载数据并根据需要将其保存 - 但您正在创造机会如果您想要多用户编辑的问题 - 至少是单个文件。
对我们来说就是这样——我们要么使用可以执行 SQL 的东西（MS 提供了一组从 .DLL 运行的工具，以执行单用户操作，一直到企业服务器，它们都使用相同的 SQL （在低端有限制））或者我们将使用 XML 作为一种格式，因为（对我们而言）冗长很少成为问题。
我们目前不必在我们的应用程序中操作二进制数据，这样就不会出现这个问题。
墨菲
于 2008-09-01T12:31:15.040 回答
1
如果应用程序数据本质上是面向键/值和分层的，则可能需要考虑使用 LDAP 服务器来代替传统的 SQL 数据库。
于 2008-09-01T15:49:49.057 回答
1
BTree 文件通常比关系数据库快得多。SQLite 在其中包含一个 BTree 库，该库位于公共域中（就像在真正的“公共域”中一样，不松散地使用该术语）。
但坦率地说，如果我想要一个多用户系统，我需要大量劝说不要使用像样的服务器关系数据库。
于 2008-09-01T22:18:20.713 回答
1
全文数据库，可通过“10字以内”等邻近算子查询。
关系数据库是用于多种用途的理想商业工具——足够容易理解和设计，足够快，即使它们不是由可以“使用全部力量”的天才设计和优化的，等等。
但是某些业务目的需要全文索引，而关系引擎要么不提供，要么事后才添加。特别是，法律和医学领域有大量的非结构化文本需要存储和浏览。
于 2008-09-15T17:51:36.710 回答
1
另外： * 嵌入式场景 - 通常需要使用比成熟的 RDBMS 更小的东西。Db4o是一个可以在这种情况下轻松使用的 ODB。* 快速或概念验证开发——您希望专注于业务而不担心持久层
于 2008-09-28T10:17:37.060 回答
1
亲吻：保持小而简单
于 2008-09-28T10:29:20.840 回答
1
CAP定理简洁地解释了它。SQL 主要提供“强一致性：所有客户端看到相同的视图，即使存在更新”。
于 2010-03-01T19:08:09.247 回答
1
我会提供 RDBMS :) 如果您不会在设置/管理方面遇到麻烦，请选择 SQLite。内置 RDBMS，具有完整的 SQL 支持。它甚至允许您在任何列中存储任何类型的数据。
对例如日志文件的主要优势：如果你有一个巨大的，你将如何在其中搜索？使用 SQL 引擎，您只需创建索引并显着加快操作。
关于全文搜索：SQLite 也有全文搜索模块。
只需享受漂亮的数据标准接口即可：)
于 2011-03-21T21:51:43.953 回答
0
不使用关系数据库的一个很好的理由是当您拥有大量数据集并希望对数据进行大规模并行和分布式处理时。谷歌网络索引就是这种情况的一个完美例子。
Hadoop 还有一个Google 文件系统的实现，称为Hadoop 分布式文件系统。
于 2008-09-01T22:10:30.077 回答
0
我强烈推荐 Lua 作为 SQLite 类型的数据存储的替代方案。
因为：
- 该语言最初被设计为一种数据描述语言
- 语法是人类可读的（XML不是）
- 可以将 Lua 块编译为二进制，以提高性能
这是已接受答案的“母语集合”选项。如果您使用 C/C++ 作为应用程序级别，那么为了读取配置/数据或将它们写出而投入 Lua 引擎（100kB 的二进制文件）是完全合理的。
于 2008-09-28T10:43:11.680 回答