Ruby On Rails / Merb comme interface pour une application de l'enregistrement de milliards

Question

Je recherche une solution back-end pour une application écrite en Ruby on Rails ou Merb permettant de gérer des données contenant plusieurs milliards d’enregistrements. J'ai le sentiment que je suis censé aller avec un modèle distribué et au moment où je regardais

HBase avec Hadoop

Couchdb

Les problèmes de solution HBase tels que je les vois - le support Ruby n’est pas très puissant et Couchdb n’a pas encore atteint la version 1.0.

Avez-vous des suggestions sur ce que vous utiliseriez pour une telle quantité de données?

Les données nécessiteront des importations assez rapides, parfois de 30 à 40 Mo à la fois, mais les importations se présenteront en morceaux. Donc, environ 95% du temps, les données seront en lecture seule.

Answer 1

En fonction de votre utilisation réelle des données, MySQL ou Postgres devrait être en mesure de gérer quelques milliards d'enregistrements sur le bon matériel. Si vous avez un volume de demandes particulièrement élevé, ces deux bases de données peuvent être répliquées sur plusieurs serveurs (et la réplication en lecture est assez facile à configurer (par rapport à la réplication multiple en écriture).

Le gros avantage de l’utilisation d’un SGBDR avec Rails ou Merb est que vous accédez à l’ensemble des excellents outils d’aide pour accéder à ces types de bases de données.

Mon conseil est de profiler réellement vos données dans deux de ces systèmes et de les utiliser à partir de là.

Answer 2

Les gens ont utilisé différentes solutions. D'après mon expérience, cela dépend vraiment de vos habitudes d'utilisation liées à ces données et non du nombre de lignes par table.

Par exemple, "Combien d'insertions / mises à jour par seconde sont effectuées." Des questions comme celles-ci joueront dans votre décision quant à la solution de base de données back-end que vous choisirez.

Prenons Google, par exemple: il n'existait pas vraiment de solution de stockage / recherche répondant à leurs besoins. Ils ont donc créé leur propre système sur la base d'un modèle Map / Reduce.

Answer 3

Un avertissement concernant HBase et d’autres projets de cette nature (je ne sais rien de CouchDB - je pense que ce n’est pas vraiment une base de données, mais simplement un magasin de valeurs-clés):

1. Hbase n’est pas réglé pour la vitesse; il est réglé pour l'évolutivité. Si la vitesse de réponse pose problème, exécutez quelques preuves de concept avant de valider ce chemin.
2. Hbase ne prend pas en charge les jointures. Si vous utilisez ActiveRecord et avez plusieurs relations, vous pouvez voir où cela se passe.

Le projet Hive, également basé sur Hadoop, prend en charge les jointures. tout comme Pig (mais ce n'est pas vraiment sql). Le point 1 s'applique aux deux. Ils sont conçus pour les tâches de traitement de données lourdes et non pour le type de traitement que vous êtes susceptible de faire avec Rails.

Si vous voulez une évolutivité pour une application Web, la seule stratégie qui fonctionne consiste à partitionner vos données et à faire le maximum pour vous assurer que les partitions sont isolées (vous n'avez pas besoin de vous parler). C'est un peu délicat avec Rails, car il suppose par défaut qu'il existe une base de données centrale. Il y a peut-être eu des améliorations à cet égard depuis que j'ai examiné la question il y a environ un an et demi. Si vous pouvez partitionner vos données, vous pouvez évoluer horizontalement assez large. Une seule machine MySQL peut traiter quelques millions de lignes (PostgreSQL peut probablement s’adapter à un plus grand nombre de lignes mais peut-être un peu plus lent).

Une autre stratégie efficace consiste à configurer un maître-esclave dans lequel toutes les écritures sont effectuées par le maître et les lectures sont partagées entre les esclaves (et éventuellement le maître). Évidemment, cela doit être fait assez soigneusement! En supposant un rapport lecture / écriture élevé, cela peut très bien s’adapter.

Si votre organisation dispose de ressources importantes, consultez les offres de Vertica, AsterData et Greenplum.

Answer 4

Le backend dépendra des données et de la manière dont elles seront accessibles.

Mais pour l'ORM, j'utiliserais probablement DataMapper et écrirais un adaptateur DataObjects personnalisé pour accéder au backend de votre choix.

Answer 5

Je ne sais pas ce que CouchDB n’est pas à 1.0 a à voir avec cela. Je recommanderais de faire quelques essais avec (générer un milliard de documents aléatoires) et de voir si ça va tenir. Je dirais que ce sera le cas, même si je n’ai pas de numéro de version spécifique.

CouchDB vous aidera beaucoup en ce qui concerne le partitionnement / partage de vos données. Il semble que cela puisse s’intégrer à votre projet - en particulier si le format de vos données peut être modifié à l’avenir (ajout ou suppression de champs) puisque les bases de données CouchDB ne pas avoir de schéma.

CouchDB regorge d’optimisations pour les applications lues en lecture et, selon mon expérience, c’est ce qui brille vraiment.