Как обрабатывать массивные запросы данных и контролировать время в течение 1 секунды? - PullRequest
2 голосов
/ 26 августа 2010

Я обдумываю проблему, если я получу таблицу, и данные в ней будут расти, тысячи, миллионы, миллиарды ....
Однажды я думаю, что даже простому запросу потребуется несколько секундбежать.Так есть ли какие-либо средства, которые мы можем использовать для контроля времени в течение 1 секунды или в любое разумное время?

Ответы [ 4 ]

3 голосов
/ 26 августа 2010
  1. Разметка. Самый быстрый ввод / вывод, который вы можете сделать, это тот, который вам не нужен.

  2. индексирование. При необходимости не для каждого столбца. Вы не можете заставить каждый запрос выполняться со скоростью памяти, поэтому вы должны выбирать.

  3. Реалистичность. Вы не обрабатываете миллиард операций ввода-вывода через реляционный движок за одну секунду.

1 голос
/ 26 августа 2010

Думаю, вам следует вики сообщества , так как правильного ответа не будет (или вы получите более конкретный ответ на свой вопрос).

Во-первых, расширение индексации Тима.Индексы дерева похожи на перевернутую пирамиду.Ваш блок Root / 'level 0' может указывать на сотню блоков 'level 1'.Каждый из них указывает на сотню блоков «уровня 2» и каждый указывает на сотню блоков «уровня 3».Это миллион блоков уровня 3, которые могут указывать на сто миллионов строк данных.Это пять операций чтения, чтобы добраться до любой строки в этом наборе данных (и, вероятно, все, кроме двух последних, кэшируются в памяти).Еще один уровень поднимает ваш набор данных на два порядка.Индексы ДЕЙСТВИТЕЛЬНО хорошо масштабируются, поэтому, если ваш сценарий использования приложения играет с небольшими объемами данных в очень большом наборе данных, у вас все в порядке.

Секционирование можно рассматривать как альтернативную форму индексации, в которой вы хотите быстроисключить значительную часть работы.

Устройства хранилища данных - это второе решение, когда вы ожидаете иметь дело с большими наборами данных в еще больших наборах данных.Как правило, решение состоит в том, чтобы перебросить диски при проблеме, с процессорами или памятью, выделенными для этих дисков или без них, для разделения проблемы.

Распределенная база данных в основном решает другую форму масштабируемости, которая заключается в большом количестве одновременных пользователей.Процессор может адресовать только столько памяти, а значит, столько пользователей, с которыми он может справиться, не борясь за память.Репликация работала до некоторой степени, особенно с более старыми приложениями для чтения.Проблема, к которой обращается новая база данных NoSQL, заключается в том, чтобы сделать это и получить согласованные результаты, включая управление резервными копиями и восстановлениями для восстановления согласованности.Как правило, они делают это, выбирая «возможную согласованность», принимая временные несоответствия в качестве компромисса для масштабируемости.

Я бы рискнул сказать, что существует немного баз данных NoSQL, где объем данных исключает решение СУБД,Скорее это был том пользователя / транзакции / записи, который выдвинул распределенные базы данных.

Твердотельное хранилище также сыграет свою роль.В последнее время проблема с вращающимися коричневыми дисками была меньше связана с производительностью вращения.Они не могут работать достаточно быстро, чтобы быстро получить доступ ко всем данным, которые вы можете хранить на них.Флэш-накопители / карты / память / кэш-память в основном убирают время поиска, которое задерживает все.

1 голос
/ 26 августа 2010

Конечно, распространите.

Вы можете использовать что-то вроде Hive (http://wiki.apache.org/hadoop/Hive) для запросов SQL.

Это займет несколько минут на запрос, если у вас есть100 тысяч строк или 100 миллиардов строк.У вас будут данные, хранящиеся на многих разных компьютерах, и, хотя это волшебство Hadoop, ваш запрос отправится туда, где живут данные, выполнит запрос этой части и вернется с результатами.

Или дляболее быстрые запросы с большим количеством ограничений, посмотрите на Hbase (http://hbase.apache.org/#Overview).Он также расположен поверх hadoop и работает немного быстрее, чем SQL.

0 голосов
/ 26 августа 2010

Индексация решит 90% ваших проблем. Чтобы найти один уникальный элемент из миллиона в двоичном дереве, потребуется пройти только 30 узлов (0,003% от общего числа записей).

В зависимости от данных вы можете составить таблицы агрегации. Поэтому, если бы вы регистрировали статистику и отбирали данные каждые 5 минут, вы могли бы просто объединить данные в таблицу, где каждая строка представляла бы среднее значение за час, день и т. Д.

...