Будет ли работать mysql с нагрузкой примерно триллион записей?

Добрый день! Знаю вопрос звучит странно, но предположим что у нас есть база данных с триллионом записей, будет ли она нормально функционировать и как это скажется на время ответа от базы?

Заранее благодарю!
  • Вопрос задан
  • 2319 просмотров
Решения вопроса 3
MaxDukov
@MaxDukov
впишусь в проект как SRE/DevOps.
вообще триллион записей по 1 байту - это уже террабайт. т.е. тут мы говорим о БД с объемом даже не в десятки - в сотни террабайт. Очень IMHO - но тут говорить о любом SQL вообще странно. Может быть хадуп?
Ответ написан
viktorvsk
@viktorvsk
Конечно, все зависит от многих условий, но в общем случае при таких объемах нужно дробить таблицы (partitioning). Как следствие, сначала нужно будет с каждой таблицы выбрать нужные данные, а далее проводить с ними какие-то операции - джойны и т.д.
Ответ написан
Комментировать
thelongrunsmoke
@thelongrunsmoke
Программист
Предположим у вас в таблице более 10^12 записей много полей и таких таблиц несколько. Работать такая база будет, но при соблюдении ряда мер. Во-первых, от релятивности придется отказаться, перестройка индексов при изменениях будет чрезвычайно ресурсоёмка. Во-вторых, требования к качеству запросов будут выше, обычный LEFT JOIN по такой таблице, и ответ может быть очень нескоро. Плюс некоторые другие проблемы, касающиеся поддержки базы.

Я бы выбрал PostgreSQL.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
jumper423
@jumper423
web-developer
Плохо раскрыли вопрос. Триллион записей в одной таблице или в миллионе таблиц по немного. Какие операции в основном нужно делать. Какая структура данных и тд и тп. Какие мощностями располагаете. Для такого большого количества записей очень много надо учесть. Может Вам больше подойдёт что-то из NoSQL.
Ответ написан
Комментировать
martin74ua
@martin74ua Куратор тега MySQL
Linux administrator
Комментировать
syschel
@syschel
freelance/python/django/backend
Проблема врятли будет в самой базе данных. Как правило всё упирается в три вещи:
1. Сами запросы и оптимизация их.
2. Конфигурация базы данных и самого сервера. Ну и правильно расставленные индексы.
3. Ресурсы сервера с базой данных.
Ответ написан
Комментировать
@AnjeyTsibylskij
Обычно, когда оперируют данными такого объема, идет деление на уровне приложения.
К примеру, записи с 1-1м лежат на одном сервере, данные с 1м-2м на другом и т.д. MySQL справиться с такой задачей, Facebook справляется. Но JOIN-ы Вы делать не сможете, а для связки Ваших данных, нужно будет реализовывать скриптовый сервер.

Главное понять данные каких типов будут храниться, возможно для Ваших задачь, MySQL, просто не подходит
Ответ написан
Комментировать
Acuna
@Acuna
Заполнил свой профиль
Если у Вас чисто теоретический вопрос - тогда так и отвечу без конкретных реализаций))) Работать будет относительно быстро, если регулярно осуществлять партицирование или сегментирование (почитайте в интернетах, очень полезная вещь даже для небольших БД). В кратце - это разделение всей БД по партициям, с которыми мускулу намного легче работать, чем с одной крупной БД. Сам мускул предоставляет отличные инструменты для этого. Более того, он сам определяет в какой партиции хранятся нужные данные уже в момент запроса. Так же при этом не накладывается совершенно никаких ограничений в работе с джоинами и индексами. Единственный минус заключается в том, что его нужно осуществлять вручную. Хотя для этого достаточно запускать простенький скрипт на кроне, который будет выполнять около сотни запросов партицирования всего раз в месяц. Нагрузки он этим почти не создаст, однако сам мускул Вам будет очень благодарен, что вы разгружаете его от ненужной работы по тасканию тяжеленных баз. Еще иногда с связке с ним реализуется шардинг, когда автоматически создается новая таблица в БД, когда в старой накопилось какое-то количество записей (как правило 10 000), c именами table1, table2, table3 и т. д. В этом случае разные БД можно вообще разнести по разным серверам, однако в большинстве случаев из-за некоторых субъективных факторов его реализация как правило неосуществима, поэтому в большинстве случаев повсеместно используется партицирование.
Также, как уже было сказано ранее - неизвестно, в каких условиях будет пользоваться Ваша БД: если запросов на добавление больше, чем на чтение - нужно пользовать MyISAM, иначе InnoDB, разница замечается. Сильно.
Ответ написан
Комментировать
PostgreSQL будет ))) MySQL ну может в принципе наверное, возможно даже один индекс по id довольно долго будет перестраиваться при вставке новых записей.
Ответ написан
Ваш ответ на вопрос

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

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