@grgdvo

Я бы не стал голословно сравнивать с bigquery. Самому мне не доводилось использовать, но предполагаю, что над каждым запросом к большим данным там трудится целый кластер из нескольких узлов, которые параллельно все собирают (ведь только на чтение работаем). Поэтому сравнение не совсем корректное, возможно pgpool + группа из postgres-серверов будут давать результат не сильно хуже, чем bigquery.

Теперь по самой задаче, что-то выбрать из большой таблицы. Вы сами бы как решали эту задачу, чтобы было очень-очень быстро?? Наверно бы использовали индексы, чтобы скакать не по всем данным, а сразу прицельно по некоторому подмножеству. Соответственно нужен правильный актуальный индекс. Пока мы данные считываем с диска в память, чтобы делать выборку, то тоже тратим время. Нужно, чтобы данные таблицы (индекса) располагались "ровненько", друг за другом, без лишних операций ввода/вывода. Как-то об этом надо бы позаботиться, плюс скорость чтения с носителя имеет значение. Хотелось бы и оперативной памяти предусмотреть больше, чтобы максимально уместить запрос без лишних сбросов/подкачек промежуточных данных. Поэтому все же!!! коли речь идет о highload в конкретной задаче, а я именно так расцениваю вашу задачу, то я бы проводил эксперименты по оптимизации. То есть еще до продакшна эмулировать нагрузку и смотреть что и как.
Ну нет на словах ничего такого специального в указанных мною условиях, в рамках которых должна действовать СУБД, чтобы максимально быстро достать заданную пользователем выборку.

Вернуться к обсуждению:
PostgreSQL vs MySQL скорость чтения PostgreSQL

0