LINUX.ORG.RU

MongoDB?

 , ,


0

1

Есть навязчивая идея перенести одну таблицу на 35 млн. записей из MySQL на MongoDB. Вопрос в том, подходит ли MongoDB для таких больших таблиц и как у неё сейчас со стабильностью? По функционалу она устраивает.

Sudo cast Vit, что ли...

И что ты от этого хочешь получить? Смысла просто перенести таблицу нет.

AlexVR ★★★★★ ()

И да, что ты хочешь делать с этой таблицей?

AlexVR ★★★★★ ()
Ответ на: комментарий от AlexVR

И что ты от этого хочешь получить? Смысла просто перенести таблицу нет.

Хочу снять нагрузку на сервер же.

И да, что ты хочешь делать с этой таблицей?

Это определенного рода логи. Нужна только виборка и запись (на уровне обчных мускульных SELECT * FROM ... и INSERT INTO).

sphericalhorse ★★★★ ()

35 млн.

приличные БД типа постргреса умеют это дело бить на части и складывать на винт, пока никому эти записи не нужны.

Rastafarra ★★★ ()

MongoDb и создана для работы с большими объемами данных и 35 млн. записей типа логи для неё ничто. Для полной уверенности можете протестить добавление и выборку вашего объёма данных. Что вы имеете ввиду под стабильностью? Если потери данных - то lf была такая проблема при сохранение в unsafe mode, что иногда данные терялись. Сейчас ситуация улучшилась + не пишите данные, для которых потеря записи критична в unsafe mode. Если вы пишит логи, то, думаю, для вас это не проблема. Наблюдаемое нытьё в блогах по поводу проблемы с неактуальностью возвращаемых данных и прочего чаще всего из-за того, что люди используют MongoDb не там где надо, не принимая во внимание принцип eventual consistency и теорему CAP: http://ru.wikipedia.org/wiki/Теорема_CAP

podelkin ()
Ответ на: комментарий от Rastafarra

да и мускуль начиная с опред момента partitions умеет, кривовато (судя по документации) но умеет.

qnikst ★★★★★ ()

35M это вообще ничто даже для mysql

Reset ★★★★★ ()
Ответ на: комментарий от sphericalhorse

Если хочешь использовать MongoDB, то смотри как будешь использовать MapReduce. Если его использовать не будешь, то зачем тебе лишняя сущность. Тем более что записей у тебя кот наплакал. Было бы их у темя over 10^10 то ещё имело бы смысл искать что-то другое.

AlexVR ★★★★★ ()

35 миллионов?
Детский сад, а не таблица.
Нагрузку можно снять оптимизацией, как минимум:

I. Дефрагментация табличного пространства:
1. Сделать дамп базы
2. Удалить файлы базы
3. В my.cfg сразу указать большой размер табличного пространства, как минимум такой-же как был у файла ibdata до удаления
4. Залить дамп в новую базу
II. Поставить Percona Server вместо стандартного ораклового, он значительно быстрее
III. Разместить табличное пространство на отдельных физических дисках с файловой системой, которая поддерживает непрерывные файлы, например XFS
IV. Если в БД производится много записей, то поставить innodb_flush_log_at_trx_commit в ноль
V. Сделать партиционирование таблиц по подходящему критерию

Только эти действия ускорят выборку раза в три-четыре. Если поработать с настройками mysql-сервера и innodb можно ещё выжать скорости.

dmitryalexeeff ()
Ответ на: комментарий от Rastafarra

приличные БД типа постргреса

А как там нынче с мастер-мастер репликацией?

KRoN73 ★★★★★ ()
Ответ на: комментарий от dmitryalexeeff

Разместить табличное пространство на отдельных физических дисках с файловой системой, которая поддерживает непрерывные файлы, например XFS

Только осторожнее нужно быть: Подскажите какую ФС использовать под нагруженный mysql сервер (комментарий)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Это да, бывает. У меня, кстати, с XFS тоже конфуз был, связанный с потерей данных.
Но, с другой стороны, на EXT4 я не смог добиться размещения 180Гб табличного пространства в непрерывном файле.

dmitryalexeeff ()

Стоит еще обратить внимание на отсутствие транзакций в обычном понимании. Лично для меня это стало критичным выбором в пользу иных БД. В плане производительности монго является почти эталоном :)

gh0stwizard ★★★★★ ()
Ответ на: комментарий от Reset

Это если нужно чтение/запись. А если нужно добавить поле к уже имеющейся таблице и при этом обеспечить как чтение так и запись, как решить такую задачку на mysql?

cobold ★★ ()

второй год работаю с монго - никому не посоветую. Говно редчайшее, тупое и тормознутое.

JFreeM ★★★☆ ()
Ответ на: комментарий от gh0stwizard

В плане производительности монго является почти эталоном

однопоточное, непараллелящее УГ?

JFreeM ★★★☆ ()

да и зачем, собственно? 35 млн записей в одной таблице, где, по видимому используются одни селекты да агрегатные функции - это ерунда даже для мускуля. Или вы там селфджоин делаете?

JFreeM ★★★☆ ()
Ответ на: комментарий от gh0stwizard

сами учите, один запрос там выполняется в один поток, если не считать шардинга

JFreeM ★★★☆ ()
Ответ на: комментарий от JFreeM

А вам что нужно? Я же говорил, что там нет нормальных транзакций, а раз нет транзакций то какой смысл запускать множество потоков для одного соединения? Я тестировал с libev на стороне клиента 1к соединений - нагрузка распределяется почти равномерно, памяти съедается конечно немеренно при заливке данных, но тормозов как и обещали авторы - нет. Основной лимит у mongo это канал до 1гб/с. Что дальше происходит - представляю, но при таких нагрузках любая база построенная на файлах свалится по cpu, сколько не крути хэш.

gh0stwizard ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.