Есть навязчивая идея перенести одну таблицу на 35 млн. записей из MySQL на MongoDB. Вопрос в том, подходит ли MongoDB для таких больших таблиц и как у неё сейчас со стабильностью? По функционалу она устраивает.
MongoDb и создана для работы с большими объемами данных и 35 млн. записей типа логи для неё ничто. Для полной уверенности можете протестить добавление и выборку вашего объёма данных.
Что вы имеете ввиду под стабильностью? Если потери данных - то lf была такая проблема при сохранение в unsafe mode, что иногда данные терялись. Сейчас ситуация улучшилась + не пишите данные, для которых потеря записи критична в unsafe mode. Если вы пишит логи, то, думаю, для вас это не проблема.
Наблюдаемое нытьё в блогах по поводу проблемы с неактуальностью возвращаемых данных и прочего чаще всего из-за того, что люди используют MongoDb не там где надо, не принимая во внимание принцип eventual consistency и теорему CAP: http://ru.wikipedia.org/wiki/Теорема_CAP
Если хочешь использовать MongoDB, то смотри как будешь использовать MapReduce. Если его использовать не будешь, то зачем тебе лишняя сущность. Тем более что записей у тебя кот наплакал. Было бы их у темя over 10^10 то ещё имело бы смысл искать что-то другое.
35 миллионов? Детский сад, а не таблица. Нагрузку можно снять оптимизацией, как минимум:
I. Дефрагментация табличного пространства: 1. Сделать дамп базы 2. Удалить файлы базы 3. В my.cfg сразу указать большой размер табличного пространства, как минимум такой-же как был у файла ibdata до удаления 4. Залить дамп в новую базу II. Поставить Percona Server вместо стандартного ораклового, он значительно быстрее III. Разместить табличное пространство на отдельных физических дисках с файловой системой, которая поддерживает непрерывные файлы, например XFS IV. Если в БД производится много записей, то поставить innodb_flush_log_at_trx_commit в ноль V. Сделать партиционирование таблиц по подходящему критерию
Только эти действия ускорят выборку раза в три-четыре. Если поработать с настройками mysql-сервера и innodb можно ещё выжать скорости.
Это да, бывает. У меня, кстати, с XFS тоже конфуз был, связанный с потерей данных. Но, с другой стороны, на EXT4 я не смог добиться размещения 180Гб табличного пространства в непрерывном файле.
Стоит еще обратить внимание на отсутствие транзакций в обычном понимании. Лично для меня это стало критичным выбором в пользу иных БД. В плане производительности монго является почти эталоном :)
Это если нужно чтение/запись. А если нужно добавить поле к уже имеющейся таблице и при этом обеспечить как чтение так и запись, как решить такую задачку на mysql?
да и зачем, собственно? 35 млн записей в одной таблице, где, по видимому используются одни селекты да агрегатные функции - это ерунда даже для мускуля. Или вы там селфджоин делаете?
А вам что нужно? Я же говорил, что там нет нормальных транзакций, а раз нет транзакций то какой смысл запускать множество потоков для одного соединения? Я тестировал с libev на стороне клиента 1к соединений - нагрузка распределяется почти равномерно, памяти съедается конечно немеренно при заливке данных, но тормозов как и обещали авторы - нет. Основной лимит у mongo это канал до 1гб/с. Что дальше происходит - представляю, но при таких нагрузках любая база построенная на файлах свалится по cpu, сколько не крути хэш.