Какую субд выбрать для больших объемов данных (десятки гигабайт — сотня гигабайт)?

Понадобилось в таблице innodb mysql размером 60 GB добавить пару индексов, использовал pt-online-schema-change, но уже почти сутки идет создание новой таблицы с новыми индексами, а размер таблицы еще не перевалил даже за 4 ГБ. Возможно есть СУБД, где изменение структуры таблицы (добавление полей, создание индексов) будет происходить не так болезненно? Также необходимо поддержка фреймворком kohana, чтобы работало ORM - очень удобно, ну и чтобы было что-то похожее на PhpMyAdmin. Что посоветуете?
  • Вопрос задан
  • 1161 просмотр
Пригласить эксперта
Ответы на вопрос 4
sanchezzzhak
@sanchezzzhak
Ля ля ля...
postgers добавлена быстрая поддержка изменения таблиц + нету проблем таких как в mysql
удаляешь данные а файлик бд не схлопывается...

ну а так решаю таким способом
создаем таблицу
create table new_post like post;
добавляем новые поля ( сразу создаем индексы (потом это будет не реально) )
далее выставляем авто инкремент с запасом на 100к+ выше.
далее делаем скрипт копирования
$limit = 10000;
        $count = 0;
        $lastId = 1;  // последний id можно менять ручками ( если скрипт зависнит)
        $endId = 70170509;  // максимальный ид в таблице, докуда копируем

$sqlTemplate = "insert into new_post ( select id, user_id, text)
from post where id > :lastId: and id < {$endId} order by id ASC limit {$limit})";

  $sql = str_replace(':lastId:', $lastId, $sqlTemplate);
        while ($res = $connection->createCommand($sql)->execute()) {
            $lastId = $connection->createCommand('SELECT id FROM new_post ORDER BY id DESC limit 1')->queryScalar();  // получаем ласт запись в новой таблице

            $count += $limit;

            file_put_contents($file,
                "processed " . number_format($count, 0, '.', ' ') . " rows\nlast id " . $lastId . "\n\n", FILE_APPEND);

            $sql = str_replace(':lastId:', $lastId, $sqlTemplate);
        }
        file_put_contents($file, "--done---\n\n", FILE_APPEND);


далее делаем меняем названия таблицы это операция быстрая.
30 гигов перегоняет за 20 минут.
смотрим разницу и до копируем оставшиеся

это аля аналог инструмента из percona-tool только не тормозит))

UPD
Запускаем скрипт из консоли, лучше всего вызвать
`screen` и сделать это фоново на случаи того если терминал зависит или интерент упадет.

Выбирайте БД под задачу у меня таблица была 120гигов статистики я выбрал аналитическую БД и бед не знаю.
Ответ написан
sim3x
@sim3x
СУБД не так много, чтоб было из чего выбирать
Есть постгрес, есть мускул, есть корпоративные субд, лицензию, на которые ты не потянешь
Но раз ты используешь пхпмайадмин - то скорее проблема не в субд, а в тебе

Найми администратора, который разрулит проблему
Ответ написан
devspec
@devspec
Помогло? Отметь решением
В принципе, любая современная БД справится с хранением указанного объема данных.
Вопрос в том, что именно вы хотите делать с этими данными.
Если накапливать, редко обращаться и скорость выборки не имеет большого значения - то сойдет любая SQL-БД.
Если накапливать и обращаться часто и быстро - нужно смотреть в сторону NoSQL-баз.
Если нужен полнотекстовый поиск - нужно смотреть в сторону ElasticSearch и/или Lucene.
В общем, нужно ориентироваться не на объем хранимых данных и индексов, а на конкретные задачи.
Ответ написан
Комментировать
@Draconian
Oracle Developer
Кроме всего прочего, я бы посоветовал сначала до конца оптимзировать существующую структуру: например, партицировать эту таблицу, создать нужные индексы для каждой партиции отдельно и т.д.
Потому что, похоже на то, что проблема совсем не в СУБД.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы