Answers:
文件系统中的纯文本文件
磁盘上的XML或JSON文件
电子表格/ CSV文件
Subversion（或类似的基于磁盘的版本控制系统）
Berkeley DB（基本上是基于磁盘的哈希表）
本地语言集合（存储在内存中或在磁盘上序列化）
自定义（手写）存储引擎
我不能声称对它们有任何了解，但是您可能还想研究对象数据库系统。
马特·谢泼德（Matt Sheppard）的回答很好（修改过），但是在考虑主轴时，我会考虑以下因素：
与RDBMSes相比，CSV文件的一个特殊优势是它们可以很容易地压缩并移动到几乎任何其他机器上。我们进行大量数据传输，并且一切都非常简单，我们只使用一个大CSV文件，并且可以使用rsync之类的工具轻松编写脚本。为了减少大CSV文件上的重复，可以使用YAML之类的东西。我不确定我是否会存储JSON或XML之类的东西，除非您有重要的关系要求。
至于未提及的替代方案，请不要忽视Hadoop，它是MapReduce的开源实现。如果您需要分析大量结构松散的数据，并且希望只添加10台以上的计算机来处理数据，那么这应该会很好。
例如，我开始尝试分析性能，该性能实际上是在大约20台机器上记录的不同功能的所有计时编号。尝试将所有内容保留在RDBMS中之后，我意识到，聚合之后，我真的不需要再次查询数据。而且，它仅对我有用，以汇总格式显示。因此，我保留了日志文件，对其进行压缩，然后将聚合的数据保留在数据库中。
请注意，我更习惯于考虑“大”尺寸。
尝试使用Prevayler：http : //www.prevayler.org/wiki/ Prevayler替代了RDBMS。在网站上有更多信息。
如果不需要ACID，则可能不需要RDBMS的开销。因此，请确定您是否首先需要它。此处提供的大多数非RDBMS答案都不提供ACID。
定制（手写）存储引擎/在某些用例中可能具有很高的性能
如果您拥有大量数据集，则可以使用HDF（分层数据格式），而不是自己滚动数据集。
http://en.wikipedia.org/wiki/Hierarchical_Data_Format：
HDF支持几种不同的数据模型，包括多维数组，栅格图像和表格。
它也像文件系统一样分层，但是数据存储在一个魔术二进制文件中。
HDF5是一套套件，可以管理非常大和复杂的数据收集。
想想PB级的NASA / JPL遥感数据。
G'day，
我能想到的一种情况是，当您建模的数据无法轻松地在关系数据库中表示时。
曾经有这样一个例子的是移动电话运营商用来监视和控制移动电话网络基站的数据库。
在几乎所有这些情况下，都使用了OO DB，无论是商业产品还是允许对象层次结构的自卷式系统。
我曾为一家大型公司开发3G监控应用程序，该公司将保持匿名，但其徽标是红酒色（-：，并且他们使用此类OO DB来跟踪内部单个单元的所有各种属性。网络。
使用通常通常完全不使用SQL的专有技术来查询此类数据库。
HTH。
干杯，
抢
几年前有一个名为JADE的RAD工具，它具有内置的OODBMS。DB引擎的早期版本也支持Digitalk Smalltalk。如果要使用非RDBMS范例对应用程序构建进行示例，则可能是一个开始。
其他OODBMS产品包括Objectivity，GemStone（您将需要获得VisualWorks Smalltalk才能运行Smalltalk版本，但也有一个Java版本）。在这个领域中还有一些开源研究项目-EXODUS及其后代SHORE浮现在脑海。
可悲的是，该概念似乎死了，可能是由于缺乏清晰可见的标准以及相对于基于SQL的RDMBS系统而言相对较差的即席查询功能。
OODBMS最适合具有核心数据结构的应用程序，这些数据最好以互连节点的图表示。我曾经说过，典型的OODBMS应用程序是一个多用户地牢（MUD），其中的房间将包含玩家的化身和其他对象。
仅使用存储在文件系统中的文件，您可以走很长一段路。RDBMS在处理斑点方面变得越来越好，但是这可能是处理图像数据等的自然方法，尤其是在查询很简单的情况下（枚举和选择单个项目）。
RDBMS中不太适合的其他内容是分层数据结构，我猜想地理空间数据和3D模型都不容易使用。
诸如Amazon S3之类的服务提供了不支持SQL的更简单的存储模型（键-值）。可伸缩性是关键。
Excel文件也很有用，特别是如果用户需要能够在熟悉的环境中操作数据并构建完整的应用程序来做到这一点不可行时。
有很多存储数据的方法-甚至“关系数据库”也涵盖了一系列简单代码库中的一系列替代方法，这些代码可操作本地文件，就好像它是单个用户的关系数据库一样，通过基于文件的系统，则可以处理多个用户，以选择大量的基于“服务器”的严重系统。
我们大量使用XML文件-您会获得结构良好的数据，用于查询的漂亮工具（如果适用）也可以进行编辑，这些都是人类可读的，因此您不必担心db引擎是否正常工作（或db引擎）。这对于本质上是只读的东西（在我们的情况中，通常不是从其他地方的数据库生成的东西）以及单用户系统中都非常有效，在单用户系统中，您只需加载数据并根据需要将其保存出来即可，但是您正在创造机会如果您想进行多用户编辑-至少要编辑一个文件，则会出现问题。
对于我们而言，我们将要么使用将执行SQL的功能（MS提供了一系列工具，这些工具从.DLL运行，可以一直到企业服务器执行单用户操作，并且它们都使用相同的SQL （在较低端有限制）），或者我们将使用XML作为格式，因为（对我们而言）冗长性很少成为问题。
目前，我们不必在应用程序中处理二进制数据，因此不会出现问题。
墨菲
BTree文件通常比关系数据库快得多。SQLite在其中包含一个BTree库，该库位于公共域中（就像在真正的“公共域”中一样，并不宽松地使用该术语）。
坦率地说，如果我想要一个多用户系统，我需要说服很多人不要使用像样的服务器关系数据库。
全文数据库，可以使用邻近运算符查询，例如“ 10个字以内”等。
关系数据库是实现多种目的的理想业务工具-易于理解和设计，足够快速，足够，即使不是由天才可以“充分利用”的天才设计和优化的。
但是某些业务目的需要全文本索引，而关系引擎要么不提供，要么事后才考虑。特别是，法律和医学领域有大量的非结构化文本可以存储和使用。
我会提供RDBMS :)如果您不会在设置/管理方面遇到麻烦，请使用SQLite。内置的RDBMS具有完整的SQL支持。它甚至允许您将任何类型的数据存储在任何列中。
相对于例如日志文件的主要优势：如果您有一个很大的日志文件，您将如何在其中搜索？使用SQL引擎，您只需创建索引并大大加快操作速度。
关于全文搜索：SQLite也具有用于全文搜索的模块。
只需享受漂亮的标准数据接口即可：)
不使用关系数据库的一个很好的理由是，当您拥有大量数据集并且想要对数据进行大规模并行和分布式处理时。Google网络索引将是这种情况的完美示例。
Hadoop还具有称为Hadoop分布式文件系统的Google文件系统的实现。
我强烈建议使用Lua替代SQLite类的数据存储。
因为：
这是已接受答案的“本机语言收集”选项。如果您使用C / C ++作为应用程序级别，则仅出于读取配置/数据或将其写入的目的而引入Lua引擎（100kB二进制）是完全合理的。