как было у нас:
Несколько десятков миллионов обьектов в нескольких десятках категорий.
Большинство категорий довольно простые, несколько полей и все, но
некоторые довольно сложные с отношениями (например, и Книги может быть
нескольков Авторов). У каждого обьекта есть источник откуда пришли
данные, в примере с Книгой, данные могут прийти из Amazon, Озона, или
введены пользователями/модераторами.
Entity - всего одно поле (merged_into_id) + data (JSON-blob)
Через AR можно искать только по id, любой остальной поиск через
sphinx.
EntitySource - тип источника, внешний id источника, entity_id, data
(JSON-blob)
С каждым объектом связан один или больше типов объекта (facets)
определяющие поля с их типами ("title":"string") и отношения (например
has_and_belongs_to_many:41 -- ссылка на другой facet). Когда обьект
загружался, инспектировались все типы (facets) связанные с ним и на их
основе уже создавались методы, отношения, еtc.
EntityComposer "пересоздавал" объект на основе EntitySources когда
источник менялся (например модератор исправил заголовок книги).
Недостатки подхода как уже упоминалось выше, DB практически не
работает, любое изменение данных требует загрузки обьекта, изменения,
сохранения что на миллионнах объектов занимает долгое время.
On Jul 27, 2:44 am, Max Lapshin <max.laps...@gmail.com> wrote:
> Насколько я понимаю, речь идет о чем-то типа того, что я делал ещё для
> профотоса: есть фотоаппарат/объектив и т.п., у них есть по две сотни
> параметров (группирующихся), которые ещё и разнотипные:
> строка/число/словарь.
>
> Пусть Серега расскажет, оказалась ли схема жизнеспособной, но для меня
> работало так:
>
> таблица devices -- тут хранятся экземпляры устройств. Разделение по
> полю kind, потому что для товаров STI был лишним -- никакого разделения
> логики нет.
> таблица attributes -- тут хранятся типы свойств. Например: title =
> "Диафрагма мин.", name = "aperture_min", prop_type = "n"
> В ней как раз писался тип значения: число, строка и т.п.
> таблица attribute_dictionaries: attribute_id, attribute_title, attribute_value
>
> таблица device_attributes: attribute_id, device_id, value_s (string),
> value_n(numeric), value_d(attribute_dictionary_id) и сюда же
> кешировалось поле prop_type
> Обратите внимание на то, что в этой таблице хранится три разных value,
> интерпретация которых зависит от значения в attributes.
> Это хорошо, правильно, и работает, потому что на value_n можно
> наложить индекс. Хранить всё в text -- очень, очень, очень плохая идея.
>
> Дальше понятно: вытаскиваем device, тянем его device_attributes,
> джойним с attributes и по необходимости attribute_dictionaries
>
> Сложно? Соразмерно сложности предметной области. Это всё оказалось
> очень удобно в перспективе, когда можно было интерпретатором
> специального языка вида:
>
> aperture_min:[2,6]
> kind: camera
> price:[15000,23000]
>
> выбрать пристойные мыльницы с хорошим объективом.
>
> Такая конструкция чрезвычайно удобна для редактирования и поиска. В
> несравненное количество раз удобнее, чем хранение JSON/YAML. Говорят,
> что так же удобно в MSSQL можно положить XML, заботать XPATH в
> реализации MS и получить то же самое. Но зачем, если это ровно та
> задача, под которую создавался SQL?
>
> Есть одна проблема: вытаскивание этих данных мучительно. Я её решил не
> самым лучшим образом: создал постгресовые типы и одним большим
> апдейтом заливал все данные одного девайса в поле cached_attributes в
> постгресовом представлении. Это было очень удобно в том смысле, что
> один UPDATE где-то на 5-10 секунд заливал кеш всей базы данных в поля.
> После этого парсил хранящееся представление и вытаскивал в нужном виде
> поле attributes, пригодное для рендеринга в шаблоне.
>
> Это решение плохо тем, что ни рельсы, ни datamapper, ни какой ещё
> другой ORM на руби, оказались совершенно бессильны перед кастомным
> типом данных в БД. В итоге засунуть этот кеш в тесты оказалось
> невозможно.
> Наверное, будет работать существенно более ресурсоёмкий способ с
> генерацией такого кеша на уровне руби: когда поправилось поле,
> аггрегируем все поля и заливаем их в один большой блоб. Но по этому
> блобу искать не получится, для этого есть прекрасно работающая таблица
> devise_attributes
>
> После всего этого я попытался залить такую структуру в mongodb.
> Собственно говоря, получил ровно тот же JSON-кеш, но без возможности
> поиска и выборки.
--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
Комментариев нет:
Отправить комментарий