网站的 SQL 数据库存储有哪些替代方案？答案

【问题标题】：What are alternatives to SQL database storage for a web site?网站的 SQL 数据库存储有哪些替代方案？
【发布时间】：2010-10-15 04:53:18
【问题描述】：

如果您的存储需求很小，那么 SQL 数据库就显得多余了。当我年轻而愚蠢的时候，我使用了一个文本文件，并在需要访问它时对其进行了flock()。这无法扩展，但我仍然觉得 Web 2.0 中完全忽略了非数据库解决方案。

是否有人不使用 SQL 数据库进行存储？有哪些替代方案？

【问题讨论】：

标签： php sql cgi lamp

【解决方案1】：

有很多选择。但是拥有 SQLite 可以为您提供 SQL 功能，并且无需大惊小怪的基于文件的存储，因此无需寻找这些替代方案。 SQLite 足够轻，可以在手机和 MP3 播放器中使用，所以我不明白它怎么会被认为是矫枉过正。

因此，除非您的应用程序需要一些非常具体的东西，否则不要打扰。大多数替代品更难使用且性能较差。

【讨论】：

"....没有必要寻找这些替代品" 什么？我可以自己决定。这个问题根本没有回答...

【解决方案2】：

SQLite 就是为此而发明的。

它只是一个包含完整 SQL 数据库的平面文件。您可以查询、更新、插入、删除，安装几乎没有开销，您只需要驱动程序（这是 PHP 中的标准配置）

SQLite 是一个实现自包含、无服务器、零配置、事务性 SQL 数据库引擎的软件库。

没有人提到这件事有点奇怪？

【讨论】：

【解决方案3】：

CouchDB (http://couchdb.apache.org/index.html) 是一个非 sql 数据库，现在似乎是一个流行的项目，以及一直存在的 Google 的 bigtable 或 GT.M (http://sourceforge.net/projects/fis-gtm)。

对象数据库也比比皆是； dbforobjects (http://www.db4o.com/)、ZODB (http://www.zope.org/Products/StandaloneZODB) 等等。

在某些用例中，所有这些都比传统 SQL 数据库更快、更简单，但没有一个比平面文件更简单。

【讨论】：

ZODB 最常与 RDBMS 一起用作存储层，所以我不确定这是否是一个很好的例子。它更像是一个 ORM。
ORM 与关系后端的概念紧密结合。 ZODB 不是。它被设计为具有可插拔存储的对象数据库。我站在我的选择旁边。 ;o)

【解决方案4】：

像google bigtable 或hadoop 这样的分布式哈希表是一个简单且可扩展的非SQL 数据库，通常比SQL 数据库更适合网站。 SQL 非常适合复杂的关系数据，但大多数网站没有这个要求。大多数网站以几种形式存储和检索数据，不需要对数据进行复杂的操作。

看看其中一个解决方案，因为它们将提供您需要的所有并发访问，但不支持传统的数据规范化理念。它们可以被认为非常类似于一堆命名的文本文件。

【讨论】：

+1 通常是正确的，但如果有人担心，SQL 是矫枉过正，那么使用 BigTable 将是超级矫枉过正。
@HalilÖzgür 我认为不是。轻量级方法只需要一个包含文件，将其数据保存在简单的结构中，并且无需使用 SQL 即可检索它。假设您只想存储一个结构，即具有 id 和 name 的元组，最多可存储 200 个项目。 SQL 和 BigTable 都是大材小用。
我不得不说我喜欢morris.github.io/microdb 它看起来比 sqlite 或 bigtable 都容易得多，因为您不需要定义任何对象模型。

【解决方案5】：

这可能取决于您的网站的动态程度。我曾经使用过使用 RCS 签入和签出文本文件的 wiki 软件。对于像 StackOverflow 或 Wikipedia 那样获得尽可能多的更新的东西，我不会推荐该解决方案。数据库的特点是它们可以很好地扩展，并且数据库引擎编写者已经弄清楚了同时访问、负载平衡、复制等所有繁琐的小细节。

【讨论】：

【解决方案6】：

我想说这并不取决于您存储的信息是少是多，而是取决于您请求存储数据的频率。数据库管理器在缓存查询方面非常出色，因此它们通常是性能方面的更好选择。但是，如果您不需要动态网页而只是加载静态数据 - 也许文本文件是更好的选择。数据以哪种格式存储（即 XML、JSON、key=pair）无关紧要 - 重要的是 I/O 操作。

当我开发 Web 应用程序时，我总是使用 RDBMS 作为主要数据持有者。如果 Web 应用程序不需要为每个请求提供动态数据，我只需应用一个缓存功能，将数据存储在一个缓存文件中，当没有新数据添加到主数据源（RDBMS）时，该文件会被请求。

【讨论】：

【解决方案7】：

我不会根据我想要存储的数据量来选择是否使用 SQL 数据库 - 我会根据我想要存储的数据的类型和方式来选择用过的。

维基百科将数据库定义为：数据库是存储在计算机系统中的记录或数据的结构化集合。而且我认为您的答案就在那里：如果您想存储诸如客户帐户、访问权限等记录，那么诸如 mySQL 或 SQLite 之类的数据库或其他任何不会过大的数据库。它们为您提供了一种久经考验且值得信赖的机制来管理这些记录。

另一方面，如果您的网站存储和交付不变的基于文件的内容，例如 PDF、报告、mp3 等，那么只需将它们存储在磁盘上定义明确的目录布局中就足够了。我还会在此处包含 XML 文档：例如，如果您有一个生产部门以 XML 格式为网站创建文章，则无需将它们放在数据库中 - 将它们存储在磁盘上并使用 XSLT 来传递它们。

您是否选择 SQL 还取决于如何检索您希望存储的内容。 SQL 显然适用于根据搜索条件检索许多记录，而目录树、XML 数据库、RDF 数据库等更有可能用于检索单个记录。

在尝试扩展高流量站点并将所有内容塞入 SQL DB 时，存储机制的选择非常重要。

【讨论】：

【解决方案8】：

这取决于您存储的内容。我的博客使用 Blosxom（用 Perl 编写，但可以为 PHP 做类似的事情），其中每个单独的条目都是一个单独的文本文件。第一行是纯文本（标题），其余的是不受限制的 HTML。遵循一些简单的规则，将它们呈现为一个简单但有效的博客框架。

它确实有缺点，但这也意味着每个帖子都是一个独立的文件，非常适合在本地计算机上更新然后发布到远程 Web 服务器。但是，这在高效查询方面是有限的，因此如果您想要与数据进行细粒度控制和基于 Web 的交互，这肯定不是一个好的选择。

【讨论】：

【解决方案9】：

检查CouchDB。

【讨论】：

【解决方案10】：

我在 .NET 项目中使用 LINQ to XML 作为数据源。这是一个小型解决方案，并使用缓存来缓解性能问题。对于只需要将数据保存在公共位置而不增加服务器要求的快速站点，我会再次这样做。

【讨论】：

【解决方案11】：

取决于您存储的内容以及访问方式。通常sql提供了很好的报告和手动管理能力。几乎所有东西都需要某种方式来管理存储的内容并对其进行报告。

【讨论】：

【解决方案12】：

在 Perl 中，我使用 DBM 或 Storable 来完成此类任务。 DBM 会在变量更新时自动更新。

【讨论】：

【解决方案13】：

SQL 数据库的下一层是ISAM（索引顺序访问方法）——基本上是表和索引，但没有 SQL，表之间也没有显式关系。只要概念基础适合您的设计，它就会很好地扩展。我有效地使用Codebase 很长时间了。

如果您想使用 SQL 数据库类型的数据，请考虑使用FileMaker。

【讨论】：

【解决方案14】：

一个简单的答案是，您可以使用任何数据存储格式，从标准定义到数据库（通常涉及协议），甚至是定制的文件格式。

您在 IT 领域做出的每一个选择都需要权衡取舍，当然网站也不例外。在 2000 年初，基于文件的论坛系统很流行，因为它允许任何技术能力有限的人编辑页面和帖子。完全静态的站点很快变得无法管理，并且内容不会从站点用户界面的升级中受益；但是，如果网站编码正确，则可以简单地将其移动到子目录，或翻录到新设计中。 CMS 和动态系统带来了它们自己的一系列问题，即它们之间尚不存在广泛采用的数据存储标准；他们经常依赖第三方插件来提供设计风格之间的功能（尽管他们的文档提倡功能和形式的分离）。

在 2016 年，不使用标准存储机制的情况非常罕见，例如 *SQL RDBMS；尽管 Jekyll 等静态站点生成器（为许多 GitHub 页面提供支持）；和诸如 October CMS 等独立参与者仍然提供基于静态文件的存储。

我个人的偏好是使用启用 *SQL 的 RDBMS，它为我提供了至少在供应商级别标准化的语法、熟悉且强大的语法，但与很多人不同，我认为这不是唯一的方法，并且在大多数情况下会提倡使用站点生成器将不必是动态的部分保存到静态存储中，因为这是在网络上生活的最便宜的方式。

TLDR;由您决定，支持 SQL 和 RDBMS 很受欢迎。

【讨论】：

【解决方案15】：

嗯，这是一个来自 OP 的开放式问题，有两个问题......围绕 SQL 替代方案和非 SQL。

一般来说，在“为什么 SQL 好”类别中……它是一个成熟且强大的标准，可提供引用完整性。 Java JDBC 完全支持它，TOAD 等工具也完全支持它，并且有许多 SQL 实现，如前面引用的 SQL-Lite。

现在特定于“用于网站”并不能特别说明任何事情。网站是否需要参照完整性？可能是。如果网站的业务性质主要是非结构化内容，那么可以考虑任何类型的持久存储，从 AWS DynamoDB 等所谓的“非 SQL”数据库到 Mongo（虽然不是粉丝）。

对于管理 SQL 存储的复杂性 - 一个建议与曾经创建的每个持久性存储的列表相比……是 AWS Aurora（RDS 服务的一部分）。它是多区域主动-主动且完全兼容 MySQL。基于 JDBC/ODBC 的驱动程序框架可以开箱即用，它有效地提供了“零管理”。

【讨论】：

【解决方案16】：

如果我是你，我会检查 XML。请参阅左侧的w3schools XML 教程部分。不使用 SQL 数据库有很多可能性。

【讨论】：

99% 的情况下，该语言支持的 XML 有更好的替代方案……对于 php，我会使用 var_export/eval，所以我不必解析任何内容。
XML 有什么问题？如果他想存储数据，并且使用数据库有点矫枉过正，我认为 XML 非常适合 imo。
XML 的问题在于它不能扩展，你最终会遇到与文本文件完全相同的问题。
XML 也是一个问题：没有类型（一切都是字符串），与其他存储类型相比，文件大小很大，而且 - xml 在 php 中不像其他文件类型那样易于使用（json 很多更简单、更小、有类型、json_(en/de)code 和 file_get_contents) - 仅此而已。