Однажды я работал с очень большой (Terabyte +) базой данных MySQL. Самая большая таблица у нас была буквально более миллиарда строк.
Это сработало. MySQL большую часть времени правильно обрабатывал данные. Это было чрезвычайно громоздко, хотя.
Простое резервное копирование и хранение данных было проблемой. Если понадобится, чтобы восстановить стол, потребуются дни.
У нас было множество таблиц в диапазоне от 10 до 100 миллионов. Любые значительные присоединения к таблицам были слишком трудоемкими и заняли бы вечность. Поэтому мы написали хранимые процедуры для «обхода» таблиц и объединения процессов с диапазонами идентификаторов. Таким образом, мы будем обрабатывать данные по 10-100 000 строк за раз (объединение с идентификаторами 1-100 000, затем 100 001-200 000 и т. Д.). Это было значительно быстрее, чем объединение против всей таблицы.
Использование индексов для очень больших таблиц, которые не основаны на первичном ключе, также намного сложнее. Mysql хранит индексы в двух частях - он хранит индексы (кроме первичного индекса) как индексы для значений первичного ключа. Таким образом, индексированный поиск выполняется в двух частях: сначала MySQL переходит к индексу и извлекает из него значения первичного ключа, которые ему нужно найти, затем выполняет второй поиск по индексу первичного ключа, чтобы найти, где находятся эти значения.
Суть в том, что для очень больших таблиц (1-200 миллионов плюс строки) индексация по таблицам является более строгой. Вам нужно меньше, более простых индексов. И выполнение даже простых операторов выбора, которые не находятся непосредственно в индексе, может никогда не вернуться. Где пункты должны попасть в индексы или забыть об этом.
Но, несмотря на это, все действительно работало. Мы смогли использовать MySQL с этими очень большими таблицами, выполнять вычисления и получать правильные ответы.