Однако стоит отметить, что, даже если бы статистика не была известна, при наличии миллиона строк процедура определения распределений значений столбцов занимает гораздо меньше времени, чем сортировка всей таблицы.
Замечание: Для сравнения показаны графики линейного, линейно-логиарифмического и квадратичного роста
Рис. 2. Производительность PostgreSQL на запросе SELECT country,age,sex,count(*) FROM people GROUP BY country,age,sex
Здесь PostgreSQL испытывала трудности при анализе данных, а не при их хранении. Система не отказывалась загружать или поддерживать базу данных с миллиардом записей; по-видимому, не возникли бы какие-либо трудности с хранением всей десятиколоночной таблицы и 6,75 миллиардами строк, если бы у меня имелся достаточный объем дисковой памяти.
Вот большая правда о больших данных в традиционных базах данных: данные в них проще засунуть, чем из них вытащить. Большая часть СУБД разрабатывается для эффективной обработки транзакций: для добавления, модификации, поиска и выборки небольших объемов информации в крупных базах данных. Данные обычно собираются в транзакционном стиле: представьте себе пользователя, входящего в некоторый Internet-магазин (выбираются учетные данные; в журнал добавляется информация о сессии), ищущего товары (данные о товарах ищутся и извлекаются, накапливается дополнительная информация о данной сессии) и производящего покупку (в базу данных заказов наносятся детальные данные о покупке, обновляется инфоормация о пользователе). Изрядное количество данных играючи добавляется в базу данных, которая (если этот магазин достаточно крупный и функционирует уже в течение некоторого времени), вероятно, уже содержит "большие данные".
Здесь нет никакой патологии; эта история повторяется повсюду в мире бесчетное число раз, каждую секунду. Неприятности начинаются, когда нам нужно взять эти данные, накопленные в течение месяцев или годов, и что-нибудь узнать на их основе – и, конечно, мы хотим получить ответ за секунды или минуты! Патологии больших данных – это патологии их анализа.