Форум сайта python.su
Приветствую всех здешних обитателей.
Есть идея написать один портальчик. Один из, скажем так, объектов, которым будет оперировать этот портальчик - это последовательность не связанных друг с другом записей с не до конца определенным количеством полей, по которым нужно производить выборку данных. По этой причине SQL отпадает сразу, поскольку я себе слабо представляю, как сделать подобный фокус с разным количеством полей для каждой записи.
Посему встал вопрос с NoSQL-инструментом. Из NoSQL-семейства я работал только с GAE.
1. MongoDB - народ плюется, мол сырая, падает без предупреждения и уведомления, не держит много потоков
любопытное чтиво: http://pastebin.com/raw.php?i=FD3xe6Jt и выдержка из:
1. MongoDB issues writes in unsafe ways by default in order to win benchmarksИ прочее в таком же духе, зато разной инфы валом.
2. MongoDB can lose data in many startling ways
3. MongoDB requires a global write lock to issue any write
4. MongoDB's sharding doesn't work that well under load
5. mongos is unreliable
6. MongoDB actually once deleted the entire dataset
7. Things were shipped that should have never been shipped
8. Replication was lackluster on busy servers
Офлайн
> MongoDB - народ плюется, мол сырая, падает без предупреждения и уведомления, не держит много потоков
юзаю 2 года, более 7 крупных проектов, работает стабильно, не разу не падала.
> как сделать подобный фокус с разным количеством полей для каждой записи.
В монге есть для этих целей массивы.
Для вашей задачи sql вроде как и не нужен.
Офлайн
Так вы вроде редиску используйте, чем она вам не подходит? Монго это хорошая ДСУБД, но её желательно ставить на 64-битный сервер иначе будет ограничен размер БД.
Офлайн
Редис, мне кажется, не очень подойдет, поскольку это “in memory” БД. Как-то плясать с виртуальной памятью там можно, но зачем, если на сайте не очень рекомендуют это делать. Вот сессии в нем хранить или какой-нибудь хитроорганизованный кэш, думаю идеально: быстро, организованно, возможность выбрать не только по ключам. Хоть та же возможность выполнить безопасно инкремент/декремент чего стоит.
o7412369815963А масштабирование используете? И какую, примерно, нагрузку у вас Монго держит?
> юзаю 2 года, более 7 крупных проектов, работает стабильно, не разу не падала.
Офлайн
Самая толстая база на данный момент 4млн документов, весит примерно 6Гб (проект крупный, база не большая), в течении 3-х месяцев растолстеет до 30млн документов.
Нагрузка маленькая - используется внутри компании, поэтому пока ни какого масштабирования.
Полнотекстовый поиск идет через sphinx search.
Офлайн
cpu
Монго очень плотно в Яндексе используется.
Думаю, сырой продукт там бы не прижился.
А статья, статья написана черт знает когда для версии то ли 1.6, то ли 1.4, поэтому просто устарела.
Помнится, в том блоге, где она была, еще в комментариях автора на место поставили.
На эту статью я когда то ответ читал от разработчиков.
Что комментаторы, что разработчик Монго писали что-то типа: ровняй руки и читай доки.
Если нужны запросы по базе средствами СУБД, то кроме Монго, и вариантов особо нет.
Neo4j.
Для Питона есть только библиотека embeded Neo4j.
Если работали с GAE, посмотрите внимательнее на Cassandra.
Но тут опять же, понадобится что-то более-менее сложное в запросах и без Hadoop не обойтись.
Плюс “портальчик” подразумевает больше чтения, чем записи. Поэтому Кассандра под вопросом.
HBase (опять же с Hadoop) может вписаться в требования с неизвестным кол-вом полей за счет column families.
Хотя это тоже попытка натянуть табличную структуру на данные.
Язык запросов бедный и расширяется “стандартным” Map/Reduce.
Офлайн
Lexander
> Монго очень плотно в Яндексе используется.
> Думаю, сырой продукт там бы не прижился.
Весьма недурная рекомендация.
o7412369815963
> Самая толстая база на данный момент 4млн документов, весит примерно 6Гб (проект крупный, база не большая).
И, если не падает, так вообще хорошо.
Спасибо всем отписавшимся. Пробуем Монго.
Всех с новым годом!
Офлайн
вот кстати статья-отзыв http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/
контора перешла на монго, вес бд 900Гб, и типа все норм.
Офлайн
Мы еще zodb используем. Тоже NoSQL. Используем для целей логгирования. Размер десятки гигабайт держит нормально. Причем 32 битная версия. По mongo не спец можно сказать только только доки прочитал.
zodb3 | mongodb
скорость - | + (это из общих соображений и литературы)
механизм транзакций +| - (кстати лучше бы его иногда не было)
автоматизация ORM +| -
QBE - | + (построилка индексов - отдельный пакет в zodb )
ссылки на подобъекты +| - (очень ограниченная поддержка ссылок в mongo)
документация +-| +
инструментарий - | +
запись на месте -| +
Capped Collections - |+
поддержка разных Языков -|+
неограниченные размеры +|- (много искусственных ограничений на размер документа кол-во коллекций и т.п.)
вложенные коллекции +|- (в mogodb насколько я понял нельзя в документ вставить коллекцию(сущность по которой можно строить индекс) и количество коллекций ограничено)
Кстати к знатокам вопрос - почему собственно zodb много меньше используется чем mongo может есть в ней проблемы которые я пока не заметил?
Отредактировано (Янв. 2, 2012 16:09:00)
Офлайн
> ссылки на подобъекты +| - (очень ограниченная поддержка ссылок в mongo)
Чем хороши ссылки в zodb?
за 2 года использования mongo я ушел от ссылок. теперь их не использую.
> вложенные коллекции +|- (в mogodb насколько я понял нельзя в документ вставить коллекцию(сущность по которой можно строить индекс) и количество коллекций ограничено)
Приведите пример, в монго по любому полю в документе можно сделать индекс. всмысле построить индекс по полю из ссылки?
> Кстати к знатокам вопрос - почему собственно zodb много меньше используется чем mongo может есть в ней проблемы которые я пока не заметил?
наверно из за того что монго популярней, про зодб не многие слышали.
кстати в зодб есть что про масштабирование? репликация, шардинг? мне кажется что она позиционируется на не большие проекты.
Офлайн