Database scalability is a VERY complicated issue; there are a LOT of issues that come into the whole process.
First, consider the lowest-hanging fruit; do you have individual tables (or columns) that are going to be containing the bulk of your data? Columns which will contain BLOBs which are > 4MB each? Those can be extracted from the database and stored on a flat-file storage system, and merely referred to from the database; right there, that can take many unwieldy solutions down to a manageable level.
If not, do you have deeply different usage patterns for different subgroupings of tables? If so, there's an opportunity right there for segmenting your database into different functional databases which can be partitioned onto different servers. A good example of this is read-mostly data, such as on webservers, which gets generated rarely (think user-specific home page data), but read frequently; that type of data can get segregated into a database (or, again, flatfile with references) that's separate from the rest of the user data).
Consider the transactional requirements of your database; can you isolate your transaction boundaries cleanly, or will there be deeply mingled transactions going on all through your database? If you can isolate your transaction boundaries, there's another potential useful boundary.
This is just touching on some of the issues involved with this sort of thing. One thing worth considering is whether or not you really need to have a database that is actually going to be huge, or if you're just trying to use the database as a persistence layer. If you're using the database just as a persistence layer, you might reconsider whether you actually need the relational nature of a database at all, or if you can get away with a smaller relational overlay on top of a simpler persistence layer. (I say this because a large quantity of solutions seem like they could get away with a thin relational layer over a large persistence layer; it's worth considering.)
好的，首先我需要向您指出此处。我不认为 MySQL 会像你想要的那样执行。我有一种不好的预感，当我说您需要研究 Oracle 安装时，您会说：“我们没有足够的现金。”但是，当我说获取最新/最好的 SQL-Server 时，您会说：“我们没有实现该目标所需的硬件。”恐怕 TB 级的数据会压垮你的 MySQL 安装。
Ok, first I need to point you to here. I don't think MySQL is going to perform like you want. I have a bad feeling that when I say you need to look into an Oracle instalation, you're going to say, "We don't have the cash for that." But, when I say get the latest/greatest SQL-Server, you're going to say, "We don't have the hardware it'll take to implement that." I'm afraid that terabytes is just flat out going to crush your MySQL instalation.
A new breed of NewSQL databases are being built to solve exactly the problem of distributing resources over multiple servers. The Clustrix database (which was built from the ground up to be a MySQL replacement) is one example that provides near-linear scale -- as you run out of CPU/Memory, you can simple add nodes.
数据库可扩展性是一个棘手的问题，您应该考虑可以解决该问题的解决方案。我相信 MySQL 可以作为解决您的问题的基础。
横向可扩展性；水平扩展数据库的能力（也称为横向扩展）是解决非常大的表和数据库问题的好技术。
Database scalability is a tough problem and you should consider solutions that can address it for you. I believe that MySQL can be used as the foundation for a solution to your problem.
Horizontal scalability; the ability to scale a database horizontally (aka scale-out) is a good technique to address the problem of very large tables and databases.
发布评论
评论（4）
数据库可扩展性是一个非常复杂的问题；整个过程中有很多问题。
首先，考虑最容易实现的目标；您是否有包含大量数据的单独表（或列）？包含 BLOB 的列 >每个4MB？这些可以从数据库中提取并存储在平面文件存储系统上，并且仅从数据库中引用；就在那里，这可以将许多笨拙的解决方案降低到可管理的水平。
如果没有，对于不同的表子组是否有截然不同的使用模式？如果是这样，就有机会将数据库分割成不同的功能数据库，这些数据库可以分区到不同的服务器上。一个很好的例子是主要读取的数据，例如网络服务器上的数据，很少生成（考虑特定于用户的主页数据），但经常读取；这种类型的数据可以分离到与其余用户数据分开的数据库（或者，再次，带有引用的平面文件）中。
考虑数据库的事务要求；您能否干净地隔离事务边界，或者整个数据库中是否会发生深度混合的事务？如果您可以隔离事务边界，那么还有另一个潜在的有用边界。
这只是涉及此类事情所涉及的一些问题。值得考虑的一件事是您是否真的需要一个实际上很大的数据库，或者您是否只是尝试使用数据库作为持久层。如果您将数据库用作持久层，您可能会重新考虑是否真的需要数据库的关系性质，或者是否可以在更简单的持久层之上使用更小的关系覆盖层。 （我这么说是因为大量的解决方案似乎可以在大的持久层上使用薄的关系层；这是值得考虑的。）
Database scalability is a VERY complicated issue; there are a LOT of issues that come into the whole process.
First, consider the lowest-hanging fruit; do you have individual tables (or columns) that are going to be containing the bulk of your data? Columns which will contain BLOBs which are > 4MB each? Those can be extracted from the database and stored on a flat-file storage system, and merely referred to from the database; right there, that can take many unwieldy solutions down to a manageable level.
If not, do you have deeply different usage patterns for different subgroupings of tables? If so, there's an opportunity right there for segmenting your database into different functional databases which can be partitioned onto different servers. A good example of this is read-mostly data, such as on webservers, which gets generated rarely (think user-specific home page data), but read frequently; that type of data can get segregated into a database (or, again, flatfile with references) that's separate from the rest of the user data).
Consider the transactional requirements of your database; can you isolate your transaction boundaries cleanly, or will there be deeply mingled transactions going on all through your database? If you can isolate your transaction boundaries, there's another potential useful boundary.
This is just touching on some of the issues involved with this sort of thing. One thing worth considering is whether or not you really need to have a database that is actually going to be huge, or if you're just trying to use the database as a persistence layer. If you're using the database just as a persistence layer, you might reconsider whether you actually need the relational nature of a database at all, or if you can get away with a smaller relational overlay on top of a simpler persistence layer. (I say this because a large quantity of solutions seem like they could get away with a thin relational layer over a large persistence layer; it's worth considering.)
好的，首先我需要向您指出此处。我不认为 MySQL 会像你想要的那样执行。我有一种不好的预感，当我说您需要研究 Oracle 安装时，您会说：“我们没有足够的现金。”但是，当我说获取最新/最好的 SQL-Server 时，您会说：“我们没有实现该目标所需的硬件。”恐怕 TB 级的数据会压垮你的 MySQL 安装。
Ok, first I need to point you to here. I don't think MySQL is going to perform like you want. I have a bad feeling that when I say you need to look into an Oracle instalation, you're going to say, "We don't have the cash for that." But, when I say get the latest/greatest SQL-Server, you're going to say, "We don't have the hardware it'll take to implement that." I'm afraid that terabytes is just flat out going to crush your MySQL instalation.
正在构建新型 NewSQL 数据库，以准确解决在多个服务器上分配资源的问题。 Clustrix 数据库（从头开始构建是为了替代 MySQL）就是一个提供近线性的示例规模——当你用完CPU/内存时，你可以简单地添加节点。
A new breed of NewSQL databases are being built to solve exactly the problem of distributing resources over multiple servers. The Clustrix database (which was built from the ground up to be a MySQL replacement) is one example that provides near-linear scale -- as you run out of CPU/Memory, you can simple add nodes.
数据库可扩展性是一个棘手的问题，您应该考虑可以解决该问题的解决方案。我相信 MySQL 可以作为解决您的问题的基础。
横向可扩展性；水平扩展数据库的能力（也称为横向扩展）是解决非常大的表和数据库问题的好技术。
Database scalability is a tough problem and you should consider solutions that can address it for you. I believe that MySQL can be used as the foundation for a solution to your problem.
Horizontal scalability; the ability to scale a database horizontally (aka scale-out) is a good technique to address the problem of very large tables and databases.