Требования такие:
1. С базой всегда работает только 1 пользователь, а база исследовательская и мелкие ошибки вполне допускаются (поэтому транзакции не нужны).
2. Основная таблица очень большая ~300 млн записей и очень тяжелая ~8 ГБайт + 10 таблиц общим весом ~30 ГБайт (причем нигде нет двоичных данных и текста, только числа, строки и даты). Размеры указаны без учета индексов.
3. Нужна максимальная скорость чтения данных (данные для записи будут получаться из инета, и в этом действии узким местом будет инет).

При таких объемах встает вопрос о необходимости сжатия данных, так как ни один жесткий диск не сможет оперативно прочитать такие объемы информации.

Основную таблицу делить не имеет смысла (там разные часто используемые характеристики объекта, которые нужны в связке), а 10 дополнительных таблиц представляеют из себя всего две колонки- id объекта и доп. характеристика (так я вынес в другие таблицы тяжелые редкоиспользуемые характеристики). Так что думаю смотреть в сторону поколоночного хранения данных не имеет смысла.

Что посоветуете?

AkinaAlekseySQLЧто посоветуете?Проанализировать условия отбора и рассмотреть возможность партиционирования основной таблицы, если удастся получить хорошее попадание условиями отбора в партицию.

Спасибо!

AkinaAlekseySQLНужна максимальная скорость чтения данных (данные для записи будут получаться из инета, и в этом действии узким местом будет инет).Вот в этом месте полное непонимание. Если узкое место - передача данных, то не пофиг на скорость чтения?

Данные будут получены один раз (большим количеством запросов через интернет), а потом будут только анализироваться в режиме "read only". Т.е. это база нужна для исследовательской работы.

AkinaAlekseySQLбудут только анализироваться в режиме "read only".Тогда вне всякого сомнения MyISAM.

В инетах пишут, что эта таблица ненадежная. А у меня ко всему прочему очень большие объемы. Не рухнет?

+ В инете не нашел бенчмарков производительности на больших данных (я не буду получить сами записи, только статистику- рассчитывать количество записей с тем или иным набором параметров, т.е. ограничение по памяти мне не грозит). Ведь может получиться, что на маленьких объемах чтения лучше MyISAM, а на больших InnoDB...

AkinaAlekseySQLВ инетах пишут, что эта таблица ненадежная. А у меня ко всему прочему очень большие объемы. Не рухнет?Ты же только читаешь! сфига бы ей вообще меняться, тем более с повреждением данных?

Но мне все же придется эту таблицу 1 раз заполнять. Не получится так, что после 100 млн. записей она будет падать, и мне надо будет начинать процедуру заполнения с начала (пока не пойму, что эта таблица "не держит" такие объемы).