Что происходит, когда запрос дает очень большие результаты

большинство использования / учебники / руководства объясняют, как использовать методы в контексте управляемой БД.

Так что, если User.where( some condition) вернет результат в десятки или сотни, разумно будет думать, что Rails / DB / server может справиться с этим.

Что произойдет, если тот же запрос вернет результат из тысяч или сотен тысяч записей? Осмелюсь ли я сказать миллион записей?

От чего это зависит? Какие ограничения накладываются Rails или оборудованием (если есть)?

И самое главное, есть ли способ обрабатывать такой большой набор данных в Rails (без сбоя всего?)


postgresql sql bigdata ruby-on-rails-3
person Nick Ginanto    schedule 19.06.2013    source источник
comment
Лучший способ обрабатывать большой набор данных - оставить его в базе данных и выполнять всю работу с ним внутри базы данных.   -  person mu is too short    schedule 19.06.2013
comment
Вопрос в том, что вам нужно делать с миллионом выбранных записей? Показать их пользователю?   -  person Yevgeniy Anfilofyev    schedule 19.06.2013
comment
Допустим, рассматриваемая таблица - это координаты времени жизни модели. Если координата берется каждую секунду, то может быть миллионы координат. Если я хочу отобразить их, мне нужно получить каждый из них (скажем, я должен и не могу использовать ярлыки)   -  person Nick Ginanto    schedule 19.06.2013
comment
@NickGinanto Postgres может обрабатывать 1 миллион объектов. Но я не знаю ни одного интерфейса, который мог бы показывать пользователю 1 миллион объектов одновременно. Может быть, вам нужно меньшее подмножество объектов?   -  person Ihor Romanchenko    schedule 19.06.2013
comment
так что, если результат больше 1 миллиона, запрос не удастся?   -  person Nick Ginanto    schedule 19.06.2013
comment
Запрос @NickGinanto Postgres не завершится ошибкой. Но ваше приложение, вероятно, будет (если вы не создадите его для обработки таких запросов).   -  person Ihor Romanchenko    schedule 19.06.2013

Ответы (2)


arrow_upward
3
arrow_downward

Главное, что PostgreSQL материализует набор результатов на диск, если он станет слишком большим. Это означает, что вы получаете удар по скорости, но при этом освобождает память для других операций.

В общем, в PostgreSQL редко когда-либо возникает необходимость отправлять клиенту сотни тысяч или миллионы строк. Ключ состоит в том, чтобы создавать ваши запросы (и с соответствующими расширениями SQL по мере необходимости), чтобы возвращать только те данные, которые нужны вашему интерфейсу, правильно агрегированные и т. Д. В базе данных. Я встречал несколько людей, которые думали, что размещение такой логики агрегации в базе данных замедляет ее (и это требует затрат времени ЦП), но затраты в этой области, как правило, хорошо окупаются много раз в ожидании дискового ввода-вывода. временные затраты и тому подобное.

Я хотел бы задать фундаментальный вопрос: «Зачем вам нужно просматривать миллионы записей?» Вы в основном говорите, что хотите сохранить их в памяти или на диске, затем передать их по сети, затем получить, а затем обработать. Это не образец эффективности. Намного лучше обрабатывать миллионы записей рядом с хранилищем и, таким образом, обменять одни затраты на ЦП на другие.

Если вам нужно что-то, способное обеспечить более сложный параллелизм внутри запросов в смешанной среде или среде DW, используйте Postgres-XC вместо ванильного PostgreSQL. Это требует значительных затрат на сложность, но в больших средах делает решаемыми иначе неразрешимые проблемы.

person Chris Travers    schedule 07.10.2013

arrow_upward
2
arrow_downward

ОК, начнем с:

Что будет, если попробовать налить ведро с водой в стакан ??

Вот и все, что говорят:

  1. Первая зависимость - это размер вашей базы данных.
  2. Для выбора миллионов строк требуется размер (миллионы * размер строки) и, следовательно, требуется много места в буфере. Потребность в пространстве значительно возрастает, если катушка соединяется дальше.
  3. Такое большое количество строк повлияет на производительность и еще больше замедлит выполнение запроса, если база данных не поддерживает параллелизм и не имеет интеллектуального оптимизатора.

В любом случае, я думаю, что если вы имеете дело с миллионами / триллионами данных, вам следует подумать о переходе на современные хранилища, такие как Teradata.

person cosmos    schedule 19.06.2013