如何让ActiveRecord与遗留的分区/分片数据库/表一起工作？

Question

感谢你花时间在google，github和这里进行了所有的搜索，我对那些重要的词( first...after /shard/fedorate)感到更困惑，我想我必须描述我遇到的具体问题，并四处打听。

我公司的数据库处理大量用户和订单，所以我们以各种方式拆分数据库和表，其中一些描述如下：

way             database and table name      shard by (maybe it's should be called partitioned by?)
YZ.X            db_YZ.tb_X                   order serial number last three digits
YYYYMMDD.       db_YYYYMMDD.tb               date
YYYYMM.DD       db_YYYYMM.tb_ DD             date too

基本的概念是数据库和表是根据字段(而不是主键)分离的，而且有太多的数据库和表，所以为每个数据库和每个表编写或神奇地生成一个database.yml配置是不可能的，或者至少不是最佳的解决方案。

我研究了drnic的神奇解决方案，datafabric，甚至活动记录的源代码，也许我可以使用ERB来生成database.yml并在环绕过滤器中进行数据库连接，也许我可以使用named_scope来动态决定查找的表名，但是更新/创建操作被绑定到"self.class.quoted_table_name“，所以我不能很容易地解决我的问题。甚至我可以为每个表生成一个模型，因为它的数量最多为30个。

但这还不够干！

我需要的是一个干净的解决方案，就像下面这样的DSL：

class Order < ActiveRecord::Base
   shard_by :order_serialno do |key|
      [get_db_config_by(key), #because some or all of the databaes might share the same machine in a regular way or can be configed by a hash of regex, and it can also be a const
       get_db_name_by(key), 
       get_tb_name_by(key),        
      ]
   end
end

有人能照亮我吗？任何帮助都将不胜感激

Answer 1

第二种情况(只更改db名称)很容易用DbCharmer实现。您需要在DbCharmer中创建own sharding method，它将根据键返回连接参数散列。

其他两种情况不会立即支持，但可以很容易地添加到您的系统中：

1. 你实现了分片方法，它知道如何在你的分片数据库中处理数据库名称，这将使你能够对你的模型进行shard_for(key)调用，以切换db connection.
2. You添加如下方法：

class MyModel < ActiveRecord::Base db_magic :sharded => { :sharded_connection => :my_sharding_method } def switch_shard(key) set_table_name(table_for_key(key)) # switch table shard_for(key) # switch connection end

• 现在你可以这样使用你的模型：

MyModel.switch_shard(key).first MyModel.switch_shard(key).count

而且，考虑到从switch_shard方法返回的shard_for(key)调用结果，可以这样使用它：

M=MyModel.switch_shard(键)#切换连接并获取连接代理m.first #调用代理m.count上的任何AR方法

Answer 2

如果您想要特定的领域特定语言，或者与遗留分片背后的逻辑相匹配的内容，那么您将需要深入研究ActiveRecord并编写一个gem来为您提供这种功能。您提到的所有现有解决方案都不一定是针对您的情况编写的。您可能能够根据自己的意愿调整任意数量的解决方案，但最终您可能必须编写自定义代码才能获得您想要的结果。

Answer 3

听起来，在这种情况下，您应该考虑不使用SQL。

如果数据集如此之大，并且可以表示为键/值对(稍加非规范化)，那么您应该考虑couchDB或其他noSQL解决方案。这些解决方案快速、完全可扩展，并且基于REST，因此易于扩展、备份和复制。

我们都使用相同的工具来解决我们所有的问题(相信我，我也在尝试)。

与重写activeRecord相比，切换到noSQL解决方案要容易得多。