MongoDB?

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

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

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

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

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

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

35 млн.

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

Постгрес там никто ставить не будет.

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

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

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

Если хочешь использовать 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

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

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

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

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

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

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

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

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

Учите матчасть, есть там потоки.

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

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