Основной вывод по монго — жаль что я его не сформулировал в самой статье — что структура базы намного ближе к коду, с ней проще работать, чем sql. Хочешь реляции? Пожалуйста. хочешь словари — пожалуйста, хочешь массив с идексом — да без проблем.
Особенно удобно в связке с основнанной на json библиотекой knockout, которая обеспечивает взаимодействие с пользователем.
В обычной не реляционной базе это была бы пачка запросов, а не 1:
Запросить товар
запросить картинки
запросить видео
запросить характеристики
…
Особенно резко все ухудшается при необходимости показать список объектов, у каждого их которых есть подобъекты — lazy loading быстро портит сокрость выполнения
Ключевая таблица — Transactions — туда пишем 1 запись с двумя (в монго можно и больше, главное чтобы сумма была 0) объектами:
{ Changes: [ { User: «User1», Amount: +X}, {User: «User2», Amount: +X } ] }
Когда нам нужно достоверно знать количество денег на счету — находим все changes по user = myid и считаем сумму.
Осталось только придумать (на вкус и цвет) стратэгию кэширования остатков, чтобы не делать полный пересчет каждый раз.
Давайте разберем пример операции, где дествительно, важно чтобы изменения нескольких объектов были сохранены именно одновременно, может что и придумаем :)
Без сомнений, вы правы, но шанс с этим столкнуться в реальной жизни минимальный. С каждым новым обновлением уверенность в надежности системы растет, скорость выхода обновлений также радует.
Пока все разборы полетов на тему «у нас пропали картинки у колясок» заканчивались выявлением неправильной работы пользователей.
У всего есть предел, в том числе в том, сколько технологий можно освоить профессионально одновременно.
Судя по сайту, neo4j не предоставляет api для .net, так что надо будет искать что-то еще [более сырое]. Вполне возможно, лучше уж забивать графы монгой.
ЧТобы реализовать object pooling в универсальный механизм сериализации / десериализации придется попотеть.
Много лет назад, когда каждый программист должен был написать свой ORM, я получил существенный выигрыш в реализации такого шаблона при получени данных от базы.
Мы наоборот, используем ms sql для ряда исключительных задач.
Основной аргумент против двойной базы — сложность восстановление информации. Бакапы не могут быть сделаны в один и тот же момент, и после восстановления системы базы не будут совпадать.
Я тоже переживал за категории в Монго — оказалось очень удобно, к примеру вот такую страницу в случае использования sql придется, наверно, кэшировать. Я не написал, но этот проект не использует OutputCaching вообще — все страницы, запросов бывает до 15 тысяч в час, рендерятся на лету.
Мы же в каждой категории сохраняем id лучших 10 товара, которые ее представляют, и потом вычитываем товары, которые ее показывают.
Запрос 1 — найти категорию
запрос 2 — найти 44 товара
Не помню сколько в сумме, где-то на уровне 1/20 секунды.
Один из прошлых проектов с деревом в 100000 узлов на ms sql безбожно тормозил.
Как только появляется «много произвольных атрибутов» то монго резко становится намного удобнее MS SQL.
1. Сходу, напрашивается сохранять всех предков в монго.
2. Насколько часто происходит перемещение объектов между папками? По сути — это единственная проблема, которую я сейчас вижу. Но мне кажется для ms sql это тоже была бы проблема.
3. 100 тысяч узлов для монго это не много. Также, за счет того что можно использовать композицию — несколько объектов в одну запись, вероятно количество объектов может быть меньшем чем в реляционном варианте.
Если хотите — могу проконсультировать в индивидуальном порядке.
0.5 GB
Индексов довольно много:
— id
— категории
— внешнему id (товары синхронизируются с 1C)
— цене
— ключевым словам для поиска
— SeoFriendlyUrl
— приоритет показа
— название
Нет, изображения храняться как файлы, в базе хранится тоьлко путь к файлу. Основной размер дают:
— описания товаров (статья)
— массив ключевых слов после стэмминга для поиска
— свойства
Не совсем ясны ваши опасения.
1) Всего размер базы у нас 18 гиг и маленькой ее никак не назовешь. Добиться аналогичной скорости работы проекта на ms sql было бы намного сложнее
2) Ну и зачем-то ж нам дан мозг, было интересно его напрячь для не тривиальных решений.
Если вас беспокоит потеря данных — не верьте слухам о том, что монго не стабильна. Сама по себе она как камень. Единственное, чего она боится, это незапланированной перезагрузки питанием без корректного завершения процесса.
Тесты показали, что выборки по случайным свойствам товаров данной категории занимают порядка 0.2-0.4 секунды, что слишком долго для веб приложений. Для фильтров мы строим что-то похоже на индексы самостоятельно без средств монго, и укладываемся в 0.01.
Сортировать данные более чем в 1000 строк монго не любит — так что в больших категориях сортировки по полям запрещены.
Если уж сильно нужно, можно считать за 1й заход id + необходимую характеристику, отсортировать в C#, а потом уже считать порцию нужных данных по id
Выделить сервер с 8GB (лучше, конечно 16GB) памяти не такая космическая задача на сегодня.
Особенно удобно в связке с основнанной на json библиотекой knockout, которая обеспечивает взаимодействие с пользователем.
PS: Тот абзац чуть поправил.
Запросить товар
запросить картинки
запросить видео
запросить характеристики
…
Особенно резко все ухудшается при необходимости показать список объектов, у каждого их которых есть подобъекты — lazy loading быстро портит сокрость выполнения
{ Changes: [ { User: «User1», Amount: +X}, {User: «User2», Amount: +X } ] }
Когда нам нужно достоверно знать количество денег на счету — находим все changes по user = myid и считаем сумму.
Осталось только придумать (на вкус и цвет) стратэгию кэширования остатков, чтобы не делать полный пересчет каждый раз.
Пока все разборы полетов на тему «у нас пропали картинки у колясок» заканчивались выявлением неправильной работы пользователей.
А вот скорость выполнения как бакапов, так и восстановления базы дейстивтельно не радует и поднимает новые вопросы.
Судя по сайту, neo4j не предоставляет api для .net, так что надо будет искать что-то еще [более сырое]. Вполне возможно, лучше уж забивать графы монгой.
ЧТобы реализовать object pooling в универсальный механизм сериализации / десериализации придется попотеть.
Много лет назад, когда каждый программист должен был написать свой ORM, я получил существенный выигрыш в реализации такого шаблона при получени данных от базы.
Основной аргумент против двойной базы — сложность восстановление информации. Бакапы не могут быть сделаны в один и тот же момент, и после восстановления системы базы не будут совпадать.
Я тоже переживал за категории в Монго — оказалось очень удобно, к примеру вот такую страницу в случае использования sql придется, наверно, кэшировать. Я не написал, но этот проект не использует OutputCaching вообще — все страницы, запросов бывает до 15 тысяч в час, рендерятся на лету.
Мы же в каждой категории сохраняем id лучших 10 товара, которые ее представляют, и потом вычитываем товары, которые ее показывают.
Запрос 1 — найти категорию
запрос 2 — найти 44 товара
Не помню сколько в сумме, где-то на уровне 1/20 секунды.
Один из прошлых проектов с деревом в 100000 узлов на ms sql безбожно тормозил.
1. Сходу, напрашивается сохранять всех предков в монго.
2. Насколько часто происходит перемещение объектов между папками? По сути — это единственная проблема, которую я сейчас вижу. Но мне кажется для ms sql это тоже была бы проблема.
3. 100 тысяч узлов для монго это не много. Также, за счет того что можно использовать композицию — несколько объектов в одну запись, вероятно количество объектов может быть меньшем чем в реляционном варианте.
Если хотите — могу проконсультировать в индивидуальном порядке.
Индексов довольно много:
— id
— категории
— внешнему id (товары синхронизируются с 1C)
— цене
— ключевым словам для поиска
— SeoFriendlyUrl
— приоритет показа
— название
— описания товаров (статья)
— массив ключевых слов после стэмминга для поиска
— свойства
1) Всего размер базы у нас 18 гиг и маленькой ее никак не назовешь. Добиться аналогичной скорости работы проекта на ms sql было бы намного сложнее
2) Ну и зачем-то ж нам дан мозг, было интересно его напрячь для не тривиальных решений.
Если вас беспокоит потеря данных — не верьте слухам о том, что монго не стабильна. Сама по себе она как камень. Единственное, чего она боится, это незапланированной перезагрузки питанием без корректного завершения процесса.
Тесты показали, что выборки по случайным свойствам товаров данной категории занимают порядка 0.2-0.4 секунды, что слишком долго для веб приложений. Для фильтров мы строим что-то похоже на индексы самостоятельно без средств монго, и укладываемся в 0.01.
Сортировать данные более чем в 1000 строк монго не любит — так что в больших категориях сортировки по полям запрещены.
Если уж сильно нужно, можно считать за 1й заход id + необходимую характеристику, отсортировать в C#, а потом уже считать порцию нужных данных по id