Datenbank-Sharding und Rails

Question

Was ist der beste Weg, mit einer Shard-Datenbank in Rails umzugehen?Sollte das Sharding auf der Anwendungsebene, der aktiven Datensatzebene, der Datenbanktreiberebene, einer Proxyebene oder etwas ganz anderem erfolgen?Was sind die Vor- und Nachteile jedes einzelnen?

Answer 1

FiveRuns haben ein Juwel namens DataFabric Dies führt Sharding auf Anwendungsebene und Master/Slave-Replikation durch.Es könnte sich lohnen, einen Blick darauf zu werfen.

Answer 2

Ich gehe davon aus, dass es sich bei Shards um horizontale Partitionierung und nicht um vertikale Partitionierung handelt (Hier sind die Unterschiede auf Wikipedia).

Erst einmal, dehnbare vertikale Trennwand Soweit Sie es verkraften können, bevor Sie über eine horizontale Partitionierung nachdenken.In Rails ist es einfach, unterschiedliche Modelle auf unterschiedliche Maschinen verweisen zu lassen, und für die meisten Rails-Sites kommt man damit weit genug.

Für die horizontale Partitionierung würde dies in einer idealen Welt am erfolgen Anwendungsschicht in Schienen.Aber obwohl es nicht schwer ist, ist es in Rails auch nicht trivial, und wenn Sie es brauchen, ist Ihre Anwendung normalerweise über den Punkt hinausgewachsen, an dem dies machbar ist, da ActiveRecord-Aufrufe überall verstreut sind.Und niemand, weder Entwickler noch Management, arbeitet gerne daran, bevor Sie es benötigen, da jeder lieber an Funktionen arbeitet, die Benutzer jetzt verwenden, als an der Partitionierung, die möglicherweise erst nach Jahren, nachdem Ihr Datenverkehr explodiert ist, ins Spiel kommt.

ActiveRecord-Ebene...Soweit ich weiß, ist es nicht einfach.Würde viele Affen-Patches in Rails-Interna erfordern.

Bei Spock Letztendlich haben wir das mit a erledigt benutzerdefinierter MySQL-Proxy und Open Source auf SourceForge als Spock-Proxy.ActiveRecord denkt, dass es mit einer MySQL-Datenbankmaschine kommuniziert, in Wirklichkeit kommuniziert es mit dem Proxy, der dann mit einer oder mehreren MySQL-Datenbanken kommuniziert, die Ergebnisse zusammenführt/sortiert und sie an ActiveRecord zurückgibt.Erfordert nur wenige Änderungen an Ihrem Rails-Code.Weitere Informationen und unsere Gründe für diesen Weg finden Sie auf der Spock Proxy SourceForge-Seite.

Answer 3

Für diejenigen unter Ihnen wie mich, die noch nie von Sharding gehört haben:

http://highscalability.com/unorthodox-approach-database-design-coming-shard

Answer 4

Rails mit mehreren Datenbanken zu verbinden ist keine große Sache – Sie haben einfach eine ActiveRecord-Unterklasse für jeden Shard, die die Verbindungseigenschaft überschreibt.Das macht es ziemlich einfach, wenn Sie Shard-übergreifende Anrufe tätigen müssen.Sie müssen dann nur noch einen kleinen Code schreiben, wenn Sie Anrufe zwischen den Shards tätigen müssen.

Ich mag Hanks Idee, die Rails-Instanzen aufzuteilen, nicht, weil es schwierig erscheint, den Code zwischen den Instanzen aufzurufen, es sei denn, Sie haben eine große gemeinsam genutzte Bibliothek.

Sie sollten auch darüber nachdenken, so etwas zu tun Masochismus bevor Sie mit dem Sharding beginnen.

Answer 5

Damit Rails mit einer replizierten Umgebung funktionieren, würde ich die Verwendung des Plugins my_replication empfehlen, das dabei hilft, die Datenbankverbindung zur Laufzeit auf einen der Slaves umzustellen

https://github.com/minhnghivn/my_replication

Answer 6

Meiner Meinung nach besteht der einfachste Weg darin, ein 1:1 zwischen Rails-Instanzen und DB-Shards aufrechtzuerhalten.