Строки строго ограничены объемом доступного дискового пространства. У нас есть SQL-серверы с сотнями миллионов строк данных. Конечно, эти серверы довольно большие.
Чтобы веб-интерфейс был быстрым, вам нужно подумать о том, как вы получаете доступ к этим данным.
Один из примеров - избегать агрегированных запросов любого типа, которые требуют обработки больших массивов данных. Такие вещи, как SUM (), могут быть убийственными в зависимости от того, сколько данных они пытаются обработать. В этих ситуациях вам гораздо лучше заранее рассчитать любые сводные или сгруппированные данные и позволить своему сайту запрашивать эти аналитические таблицы.
Далее вам нужно разделить данные. Разделите эти разделы по разным дисковым массивам. Когда SQL нужно перейти на диск, это упрощает распараллеливание операций чтения. (@Simon коснулся этого).
По сути, проблема сводится к тому, сколько данных вам нужно получить в любой момент времени. Это основная проблема независимо от количества данных, которые у вас есть на диске. Даже небольшие базы данных могут быть забиты, если диски работают медленно и объем доступной оперативной памяти на сервере БД недостаточен для хранения достаточного количества БД в памяти.
Обычно для таких систем большие объемы данных в основном инертны, что означает, что к ним редко обращаются. Например, система PO может хранить историю всех счетов, когда-либо созданных, но в действительности они имеют дело только с любыми активными.
Если ваша система предъявляет аналогичные требования, то у вас может быть таблица для активных записей, и вы просто архивируете их в другую таблицу как часть ночного процесса. Вы могли бы даже пересчитать статистику, такую как среднемесячные значения (например), как часть этого архива.
Просто некоторые мысли.