Gem, который обеспечивает доступ к данным с использованием осколочных баз данных mysql при сохранении использования Activerecord - PullRequest
Новая
       2

Gem, который обеспечивает доступ к данным с использованием осколочных баз данных mysql при сохранении использования Activerecord

3 голосов
/ 28 августа 2010

Это относительно сложная проблема, о которой я думаю, поэтому, пожалуйста, предложите внести изменения или прокомментировать те части, которые вам не ясны.Я буду обновлять и повторять на основе ваших комментариев

Я подумываю о разработке самоцвета rails, который упростит использование сегментированных таблиц, даже если большая часть ваших данных хранится в реляционных базах данных.Я полагаю, что это похоже на концепцию, используемую в Quora или Friendfeed, когда они сталкиваются с масштабированием стены с традиционным mysql, с большинством потенциальных решений, требующих масштабной миграции (nosql), или просто очень болезненными (придерживаясь w полностью)

По сути, как мы можем продолжать использовать MySQL для многих вещей, в которых он действительно хорош, но при этом позволяясистемы масштабировать?Это позволит кому-то начать использовать mysql / activerecord, но столкнется с проблемой масштабирования, чтобы легко масштабировать те части базы данных, которые имеют смысл.

Для нас мы используем Ruby on Rails в изолированной базе данных и храним в них BLOB-объекты JSON.Поскольку мы не можем делать соединения, мы создаем таблицы для отношений между сущностями.

Например, у нас есть 10 различных типов сущностей.Каждая сущность может быть связана друг с другом с помощью больших (заштрихованных) таблиц отношений.

Таблицы чрезвычайно просты.Индексы (Id1, Id2 ..., тип), а данные хранятся в BLOB-объекте JSON.

  • Id, тип, {данные json}
  • Id1, Id2, тип {данные json}
  • Id1, Id2, Id3, тип {данные json}

Мы проделали большую работу по созданию интерфейсов более высокого уровня для хранения диапазона наборов данных для реляционных данных

Для любого данного типа вы можете определить тип хранилища - (значение, невзвешенный список, взвешенные списки, взвешенные списки с направляющими)

У нас есть интерфейсы более высокого уровня для каждого из них - запросы, сортировка, сравнение меток времени, пересечения и т. д.

Таким образом, если кто-топонимает, что им нужно масштабировать определенную часть базы данных, они могут хранить большую часть своей инфраструктуры и перемещать только те таблицы, которые им нужны, в эту изолированную базу данных

Что вы думаете?Как уже упоминалось выше, я хотел бы знать, что вы, ребята, думаете

1 Ответ

0 голосов
/ 01 апреля 2012

Масштабируемость - крепкий орешек.Мой опыт работы - два года в качестве инженера по продажам систем BEA, когда они продавали только промежуточное программное обеспечение TUXEDO (TUXEDO == Транзакции для UNIX Extended для распределенных операций).TUXEDO по-прежнему является королем эталона TPC-C на платформах Unix.

Масштабирование WRT базы данных - это не столько сама база данных, сколько вопрос доступа к ней.Например, если вы устанавливаете соединение с базой данных и хотите, чтобы это единственное соединение масштабировалось, то оно всегда будет обращаться к одной и той же таблице в базе данных.Проблема современных инфраструктур (включая RoR) заключается в том, что когда они открывают общие соединения, эти соединения получают доступ ко многим таблицам в базе данных.

Поэтому, если вы хотите сделать масштаб CONNECTION базы данных, сделайте это соединение сосредоточенным механизмом базы данных на как можно меньшем количестве ресурсов базы данных.Если вам удастся создать «сфокусированное» соединение, которое ТОЛЬКО обращается к одной таблице и, например, к одному индексу таблицы, оно будет масштабироваться намного лучше, чем соединение, которое обращается к КАЖДОЙ таблице в базе данных и каждому индексу, определенному для всех этих таблиц.

...