网站的 SQL 数据库存储有哪些替代方案？
如果您的存储需求很小，那么 SQL 数据库就显得有些过分了。 当我年轻又愚蠢的时候，我使用了一个文本文件，并在需要访问它时对它进行了 flock() 编辑。 这无法扩展，但我仍然觉得非数据库解决方案在 Web 2.0 中已被完全忽略。
有人不使用 SQL 数据库进行存储吗？ 有哪些替代方案？
An SQL database is overkill if your storage needs are small. When I was young and dumb, I used a text file and flock()ed it when I needed to access it. This doesn't scale, but I still feel that non-database solutions have been completely ignored in Web 2.0.
Does anyone not use an SQL database for storage? What are the alternatives?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（16）
有很多替代方案。 但是，有了 SQLite，它可以为您提供 SQL 功能，并且无需麻烦的基于文件的存储，因此无需寻找这些替代方案。 SQLite 足够轻，可以在手机和 MP3 播放器中使用，所以我不认为它被认为是一种矫枉过正。
因此，除非您的应用程序需要非常具体的东西，否则不要打扰。 大多数替代方案都更难使用并且性能较差。
There are a lot of alternatives. But having SQLite which gives you SQL power combined with no fuss of file based storage, there is no need to look for these alternatives. SQLite is light enough to be used in cell phones and MP3 players, so I don't see how it could be considered an overkill.
So unless your application needs something very specific, don't bother. Most alternatives are a lot harder to use and have less performance.
SQLite 就是为此而发明的。
它只是一个包含完整 SQL 数据库的平面文件。 您可以查询、更新、插入、删除，安装几乎没有任何开销，您所需要的只是驱动程序（PHP 中的标准配置）
有点奇怪，没人提到这一点吗？
SQLite is invented for this.
It's just a flat-file that contains a complete SQL database. You can query, update, insert, delete, there's little to no overhead in installation and all you need is the driver (which comes standard in PHP )
Kind of weird that nobody mentioned this already?
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 数据库更快、更简单，但没有一个能达到平面文件的简单性。
CouchDB (http://couchdb.apache.org/index.html) is a non-sql database, and seems to be a popular project these days, as well as Google's bigtable, or GT.M (http://sourceforge.net/projects/fis-gtm) which has been around forever.
Object databases abound as well; dbforobjects (http://www.db4o.com/), ZODB (http://www.zope.org/Products/StandaloneZODB), just to name a few.
All of these are supposedly faster and simpler than traditional SQL databases for certain use cases, but none approach the simplicity of a flat file.
分布式哈希表，例如 google bigtable 或 hadoop 是一个简单且可扩展的非 SQL 数据库，通常比 SQL 数据库更适合网站。 SQL 非常适合复杂的关系数据，但大多数网站没有此要求。 大多数网站以几种形式存储和检索数据，不需要对数据运行复杂的操作。
看一下这些解决方案之一，因为它们将提供您需要的所有并发访问，但不遵循数据规范化的传统思想。 它们可以被认为非常类似于一堆命名的文本文件。
A distributed hash table like google bigtable or hadoop is a simple and scalable non SQL database and often suits the websites far better than a SQL database. SQL is great for complex relational data, but most websites don't have this requirement. Most websites store and retrieve data in a few forms and don't need to run complex operations on the data.
Take a look at one of these solutions as they will provide all of the concurrent access that you need but don't subscribe to the traditional ideas of data normalisation. They can be thought of as pretty analogous to a bunch of named text files.
这可能取决于您网站的动态程度。 我曾经使用过 wiki 软件，它使用 RCS 来签入和签出文本文件。 对于像 StackOverflow 或 Wikipedia 那样获得如此多更新的东西，我不会推荐该解决方案。 数据库的特点是它们具有良好的可扩展性，并且数据库引擎编写者已经弄清楚了并发访问、负载平衡、复制等所有繁琐的小细节。
It probably depends how dynamic your web site is. I used wiki software once that used RCS to check in and out text files. I wouldn't recommend that solution for something that gets as many updates as StackOverflow or Wikipedia. The thing about database is that they scale well, and the database engine writers have figured out all the fiddly little details of simultaneous access, load balancing, replication, etc.
我想说，这并不取决于您存储的信息是更少还是更多，而是取决于您请求存储数据的频率。 数据库管理器在缓存查询方面非常出色，因此它们通常是性能方面更好的选择。 然而，如果您不需要动态网页而只是加载静态数据 - 也许文本文件是更好的选择。 数据以哪种格式存储（即 XML、JSON、key=pair）并不重要 - I/O 操作对性能要求很高。
当我开发 Web 应用程序时，我总是使用 RDBMS 作为主要数据持有者。 如果 Web 应用程序不需要在每次请求时提供动态数据，我只需应用缓存功能，将数据存储在缓存文件中，当没有新数据添加到主数据源（RDBMS）时，该缓存文件就会被请求。
I would say that it doesn't depend on whether you store less or more information, it depends on how often you are requesting the stored data. Databasemanagers are superb on caching queries, so they are often the better choice performance wise. How ever, if you don't need a dynamic web page and are just loading static data - maybe a text file is the better option. Which format the data is stored in (i.e. XML, JSON, key=pair) doesn't matter - it's I/O operations that are performance heavy.
When I'm developing web applications, I always use a RDBMS as the primary data holder. If the web application don't need to serve dynamic data at every request, I simply apply a cache functionality storing the data in a cache file that gets requested when no new data have been added to the primary data source (the RDBMS).
我不会根据我想要存储的数据量来选择是否使用 SQL 数据库 - 我会根据我想要存储的数据类型以及如何使用它来选择。
维基百科将数据库定义为：数据库是存储在计算机系统中的记录或数据的结构化集合。 我认为你的答案就在那里：如果你想存储诸如客户帐户、访问权限等记录，那么诸如 mySQL 或 SQLite 之类的数据库并不过分。 它们为您提供了一种经过验证且值得信赖的机制来管理这些记录。
另一方面，如果您的网站存储并提供不变的基于文件的内容，例如 PDF、报告、mp3 等，那么只需将它们存储在磁盘上明确定义的目录布局中就足够了。 我还将在这里包含 XML 文档：例如，如果您有一个生产部门以 XML 格式为网站创建文章，则无需将它们放入数据库中 - 将它们存储在磁盘上并使用 XSLT 来交付它们。
您是否选择 SQL 还取决于您希望存储的内容的检索方式。 SQL 显然适合根据搜索条件检索许多记录，而目录树、XML 数据库、RDF 数据库等更可能用于检索单个记录。
当尝试扩展高流量站点时，存储机制的选择非常重要，并且将所有内容填充到 SQL DB 中将很快成为瓶颈。
I wouldn't choose whether to use an SQL database based on how much data I wanted to store - I would choose based on what kind of data I wanted to store and how it is to be used.
Wikipeadia defines a database as: A database is a structured collection of records or data that is stored in a computer system. And I think your answer lies there: If you want to store records such as customer accounts, access rights and so on then a DB such as mySQL or SQLite or whatever is not overkill. They give you a tried and trusted mechanism for managing those records.
If, on the other hand, your website stores and delivers unchanging file-based content such as PDFs, reports, mp3s and so on then simply storing them in a well-defined directory layout on a disk is more than enough. I would also include XML documents here: if you had for example a production department that created articles for a website in XML format there is no need to put them in a DB - store them on disk and use XSLT to deliver them.
Your choice of SQL or not will also depend on how the content you wish to store is to be retrieved. SQL is obviously good for retrieving many records based on search criteria whereas a directory tree, XML database, RDF database, etc are more likely to be used to retrieve single records.
Choice of storage mechanism is very important when trying to scale high-traffic site and stuffing everything into a SQL DB will quickly become a bottleneck.
这取决于您存储的内容。 我的博客使用 Blosxom（用 Perl 编写，但也可以用 PHP 完成类似的事情），其中每个单独的条目都是一个单独的文本文件。 第一行是纯文本（标题），其余是不受限制的 HTML。 遵循一些简单的规则，这些规则将形成一个简单但有效的博客框架。
它确实有缺点，但也意味着每个帖子都是一个独立的文件，非常适合在本地计算机上更新，然后发布到远程 Web 服务器。 不过，这在高效查询方面是有限的，因此如果您想要细粒度的控制和基于 Web 的数据交互，这当然不是一个好的选择。
It depends what you are storing. My blog uses Blosxom (written in Perl but a similar thing could be done for PHP) where each individual entry is a separate text file. The first line is plain text (the title) and the rest is unrestricted HTML. Following a few simple rules, these are rendered to form a simple but effective blogging framework.
It does have drawbacks but it also means that each post is a discrete file, which works well for updating on a local machine and then publishing to a remote web server. This is limited when it comes to efficient querying though, so certainly not a good choice if you want fine-grained control and web-based interaction with your data.
检查 CouchDB。
Check CouchDB.
我在 .NET 项目中使用 LINQ to XML 作为数据源。 这是一个小型解决方案，并使用缓存来减轻性能问题。 对于只需要将数据保存在一个公共位置而不增加服务器要求的快速站点，我会再次这样做。
I have used LINQ to XML as a data source in a .NET project. It was a small solution, and used caching to mitigate performance concerns. I would do it again for the quick site that just needs to keep data in a common place without increasing server requirements.
取决于您存储的内容以及您需要如何访问它。 一般来说，sql 提供了很好的报告和手动管理能力。 几乎所有事物都需要某种方式来管理存储的内容并报告其内容。
Depends on what you're storing and how you need to access it. Generally sql provides great reporting and manual management ability. Almost everything needs some way to manage what's stored and report on it.
在 Perl 中，我使用 DBM 或 Storable 来完成此类任务。 当变量更新时，DBM会自动更新。
In Perl I use DBM or Storable for such tasks. DBM will update automatically when variable is updated.
SQL 数据库的下一级是 ISAM（索引顺序访问方法） - 基本上是表和索引但没有 SQL，表之间也没有明确的关系。 只要概念基础适合您的设计，它就能很好地扩展。 我已经有效使用 Codebase 很长时间了。
如果您想使用 SQL 数据库类型数据，请考虑 FileMaker。
One level down from SQL databases is an ISAM (Indexed Sequential Access Method) - basically tables and indexes but no SQL and no explicit relationships among tables. As long as the conceptual basis fits your design, it will scale nicely. I've used Codebase effectively for a long time.
If you want to work with SQL-database-type data, then consider FileMaker.
一个简单的答案是，您可以使用任何数据存储格式，从标准定义到数据库（通常涉及协议），甚至是定制的文件格式。
您在 IT 领域所做的每一个选择都需要权衡，当然网站也不例外。 在 2000 年初，基于文件的论坛系统很流行，因为它允许技术能力有限的任何人编辑页面和帖子。 完全静态的网站很快就会变得难以管理，并且内容不会从网站用户界面的升级中受益； 然而，如果编码正确，该站点可以简单地移动到子目录，或复制到新设计中。 CMS 和动态系统带来了它们自己的一系列问题，即它们之间尚不存在广泛采用的数据存储标准； 他们经常依赖第三方插件来提供设计风格之间的功能（尽管他们的文档主张功能与形式的分离）。
在 2016 年，不使用标准存储机制（例如 *SQL RDBMS）的情况相当罕见； 尽管静态站点生成器如 Jekyll（为许多 GitHub 页面提供支持）； 独立厂商（例如 October CMS）仍然提供基于静态文件的存储。
我个人偏好是使用支持 *SQL 的 RDBMS，它为我提供了至少在供应商级别上标准化的语法、熟悉且强大的语法，但与很多人不同的是，我认为这不是唯一的方法，并且大多数情况下会提倡使用站点生成器将不必动态的部分保存到静态存储中，因为这是在网络上生存的最便宜的方式。
太长了； 这取决于你，SQL & 支持的 RDBMS 很受欢迎。
A Simple answer is that you can use any data storage format, from standard defined, to database (which generally involved a protocol), even a bespoke file-format.
There are trade-offs for every choice you make in IT, and certainly websites are no different. In the early 2000's file-based forum systems were popular as it allows anyone with limited technical ability to edit pages and posts. Completely static sites swiftly become unmanageable and content does not benefit from upgrades to the site user-interface; however the site if coded correctly can simply be moved to a sub-directory, or ripped into the new design. CMS's and dynamic systems bring with them their own set of problems, namely that there does not yet exist a widely adopted standard for data storage amongst them; that they often rely on third-party plugins to provide features between design styles (despite their documentation advocating for separation of function & form).
In 2016, it's pretty uncommon not to use a standard storage mechanism, such as a *SQL RDBMS; although static site generators such as Jekyll (powers a lot of GitHub pages); and independent players such as October CMS still provision for static file-based storage.
My personal preference is to use an *SQL enabled RDBMS, it provides me syntax that is standardised at least at the vendor level, familiar and powerful syntax, but unlike a lot of people I don't think this is the only way, and in most cases would advocate for using a site-generator to save parts that don't have to be dynamic to a static store as this is the cheapest way to live on the web.
TLDR; it's up to you, SQL & RDBMS backed are popular.
嗯，这是 OP 提出的一个开放式问题，有两个问题……围绕 SQL 替代方案和非 SQL。
一般来说，在“为什么 SQL 很好”类别中......它是一个提供引用完整性的成熟且强大的标准。 Java JDBC 完全支持它，TOAD 等工具也完全支持它，还有许多 SQL 实现，例如前面提到的 SQL-Lite。
现在具体到“针对一个网站”并没有特别说明什么。 网站需要引用完整性吗？ 或许。 如果网站的业务本质主要是非结构化内容，那么人们可以考虑任何类型的持久存储，从所谓的“无 SQL”数据库，如 AWS DynamoDB 到 Mongo（尽管不是粉丝）。
为了管理 SQL 存储的复杂性 - 一个建议与曾经创建的每个持久性存储的列表相比......是 AWS Aurora（RDS 服务的一部分）。 它是多区域双活且完全兼容 MySQL。 基于 JDBC/ODBC 的驱动程序框架可以开箱即用，并且有效地提供“零管理”。
Well, this is a bit of an open-ended question from the OP and there are two questions ... around SQL alternatives and non-SQL.
In general, in the "Why is SQL good" category ... it's a mature and robust standard that provides referential-integrity. Java JDBC supports it fully as do tools like TOAD and there a many SQL implementations such as SQL-Lite referenced earlier.
Now specific to a "for a web-site" is not particularly indicative of anything. Does a web-site need referential integrity? Maybe. If the business nature of the web-site is largely unstructured content, then one can consider any kind of persistent storage really from so called "no-SQL" databases like AWS DynamoDB to Mongo (not a fan though).
For managing the complexities of SQL stores - one suggestion versus a list of every persistence store ever created ... is AWS Aurora (part of RDS service). It is multi-region active-active and fully MySQL-compliant. JDBC/ODBC based driver frameworks would work out-of-the-box and it effectively offers "zero administration".
如果我是你，我会检查 XML。 请参阅左侧的 w3schools XML 教程部分。 无需使用 SQL 数据库即可实现大量可能性。
I would check out XML if I were you. See w3schools XML tutorial section on the left side. Tons of possibilities without using SQL database.