设置多个具有可扩展性选项的 MySQL 数据库
我需要设置一个 MySQL 环境，该环境将支持随着时间的推移添加许多独特的数据库（实际上是数千个）。 我假设在某个时候我需要开始添加 MySQL 服务器，并且希望我的环境提前为这种情况做好准备，以便轻松过渡到第二个、第三个、第 100 个服务器。
有趣的是，如果对解决方案进行建模，以便查询数据库的应用程序将所有查询发送到单个地址并接收结果，那将非常方便。 它应该不知道服务器的数量和位置。 数据库名称是唯一的，可用于确定哪个服务器保存该数据库。
我做了一些研究，MySQL Proxy 成为主要候选者，但我还没有找到任何关于使其执行上述操作的具体信息。
任何人？
I need to set up a MySQL environment that will support adding many unique databases over time (thousands, actually).
I assume that at some point I will need to start adding MySQL servers, and would like my environment to be prepared for the case beforehand, to make the transition to a 2nd, 3rd, 100th server easy.
And just to make it interesting, It would be very convenient if the solution was modeled so the application that queries the databases sends all the queries to a single address and receives a result. It should be unaware of the number and location of the servers. The database name is unique and can be used to figure out which server holds the database.
I've done some research, and MySQL Proxy pops out as the main candidate, but I haven't been able to find anything specific about making it perform as described above.
Anyone?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的问题听起来与我们面临的问题类似 - 您充当白标，并且每个客户都需要拥有自己的单独数据库。 假设这个概念与您的概念相似，我们所做的是利用“主”数据库来存储客户端的主机名和数据库名称（可以缓存在应用程序层中）。 然后，客户端访问的服务器可以动态地将其数据源转移到所需的数据库。 这使我们能够扩展到数千个分散在服务器上的客户端数据库。
Your problem sounds similar to one we faced - that you are acting as a white-label, and that each client needs to have their own separate database. Assuming this concept parallels yours, what we did was leverage a "master" database that stored the hostname and database name for the client (which could be cached in the application tier). The server the client was accessing could then dynamically shift its datasource to the required database. This allowed us to scale up to thousands of client databases, scattered across servers.
很好的问题。 我知道有几家公司已经做到了这一点（Facebook 是最大的）。 没有一个是快乐的，但其他选择也有点糟糕。
还有更多事情需要您考虑——当其中一些数据库或服务器发生故障时会发生什么？ 当您需要执行跨数据库查询时会发生什么（即使您现在不这么认为，您也会这样做）。
这是 FriendFeed 解决方案： http://bret.appspot.com/entry/how- friendfeed-uses-mysql
这有点“back-asswards”，因为他们基本上使用 MySQL 作为一个美化的键值存储。 我不知道他们为什么不直接去掉中间人并使用 BerkeleyDB 之类的东西来存储他们的对象。 连接管理，也许吧？ 看起来 MySQL 开销对于那些可以很容易添加的东西来说代价太高了（著名的最后一句话）。
（我认为）您真正寻找的是分布式无共享数据库。 其中一些是基于 MySQL 和 PostgreSQL 等开源技术构建的，但没有一个是免费提供的。 如果您有购买意愿，请查看以下公司：Greenplum、AsterData、Netezza、Vertica。
还有大量各种分布式键值存储解决方案。 由于缺乏更好的参考，这里是一个起点： http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ 。
Great question. I know of several companies that have done this (Facebook jumps out as the biggest). None are happy, but alternatives kind of suck, too.
More things for you to consider -- what happens when some of these databases or servers fail? What happens when you need to do a cross-database query (and you will, even if you don't think so right now).
Here's the FriendFeed solution: http://bret.appspot.com/entry/how-friendfeed-uses-mysql
It's a bit "back-asswards" since they are basically using MySQL as a glorified key-value store. I am not sure why they don't just cut out the middleman and use something like BerkeleyDB for storing their objects. Connection management, maybe? Seems like the MySQL overhead would be too high a price to pay for something that could be added pretty easily (famous last words).
What you are really looking for (I think) is a distributed share-nothing database. Several have been built on top of open-source technologies like MySQL and PostgreSQL, but none are available for free. If you are in the buying mood, check out these companies: Greenplum, AsterData, Netezza, Vertica.
There is also a large number of various distributed key-value storage solutions out there. For lack of a better reference, here's a starting point: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ .