Время выполнения для различных запросов СУБД?

Существуют ли надежные (т.е. подтвержденные) данные о времени выполнения различных запросов, таких как различные типы соединений, сканирования, с различными типами и размерами данных? Я ищу порядок величины. Это не обязательно должны быть данные конкретного поставщика.

Это должно быть похоже с точки зрения представления для задержки для различного доступа. раз. (Нажмите «Просмотреть ответ».)

Причина, по которой я ее ищу, заключается в том, чтобы решить, следует ли мне вообще использовать СУБД для проекта, над которым я работаю. Мне не нужны сложные соединения, и я могу обойтись локальным кэшем памяти или даже доступом к диску.

Согласно запросу, часть проекта, для которой может потребоваться RMDBS, полностью локальна на одном узле. Узел может хранить данные любого типа, и любое чтение/запись основано на ключе, поскольку он рассматривает свой компонент хранения как огромный словарь. Он может попытаться выполнить итерацию по объектам, и может быть один объект, который предоставляет список для этих объектов. Этот вид итерации может быть чем-то вроде «Найти все объекты, которые имеют этот атрибут» (т.е. найти все строки, для которых столбец соответствует этому значению). Это та часть, в которой я не уверен - сколько преимуществ даст мне РСУБД, если вообще даст? Не вижу необходимости в соединениях.

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


person Oliver Zheng    schedule 31.12.2009    source источник
comment
на это действительно невозможно ответить каким-либо осмысленным образом без более подробной информации о типе данных, проблеме, которую вы пытаетесь решить, ожидаемом использовании и т. д. вам лучше просто описать проект и определить, подходит ли СУБД на основе этого .   -  person matt b    schedule 31.12.2009
comment
Помню, один мой профессор однажды сказал, что было бы глупо реализовывать СУБД самостоятельно. Я думаю, что его цитата звучала примерно так: как вы думаете, вы как личность могли бы сравниться с производительностью системы, которая была разработана очень умными людьми в течение последних 30 или около того лет? Конечно, доступ к файлу выполняется быстрее, чем поиск в базе данных, но вы говорите о выполнении поиска и поиске по разным типам данных. Я бы дважды подумал о реализации собственной СУБД.   -  person Brad    schedule 31.12.2009


Ответы (3)


Движение "No SQL" может принять решение о поиске альтернативы реляционным базы данных хорошая идея.

Но ни при каких обстоятельствах я бы не стал пытаться внедрить технологию персистентности самостоятельно.

На ваш вопрос невозможно ответить в общих чертах.

Лучший способ справиться с этим, который я могу придумать, — это написать общий интерфейс сохранения, который позволяет вам менять реализации. Напишите реляционную реализацию и другую технологию по вашему выбору. Сравните два и посмотрите, какой из них работает в реальных условиях для вашей ситуации. Будь ученым - получи данные. Создание его самостоятельно, а не в зависимости от форума, кажется мне разумным подходом.

person duffymo    schedule 31.12.2009

Из вашего описания кажется, что вам не нужна RDMS.

Используете ли вы доступ к данным на языке SQL... или ваше использование довольно предсказуемо.

РСУБД имеет много уровней накладных расходов, таких как синтаксический анализ операторов SQL.

Если вы можете просто хранить данные в памяти и в файловой системе, не требуя доступа к языку SQL, у вас есть возможность сделать систему быстрее.

Надеюсь, это поможет. Иван

person Ivan Novick    schedule 31.12.2009

На вопрос о времени для каждого типа запроса сложно ответить прямо, но я попытаюсь. Мне лично также нравится знать абсолютное время различных операций. Я думаю, что для простого доступа по ключу вы можете ожидать 10-20 миллисекунд на простой SQL. Еще одна цифра - если вы хотите прочитать много данных из одной таблицы, вы можете рассчитывать на получение сотен мегабайт в секунду на сервере с одним современным процессором. Что касается выбора сервера РСУБД - для простых запросов лучше всего подойдут простые механизмы РСУБД, такие как MySQL. Если запросы станут сложными - то более серьезные движки вроде Oracle, DB2, SQLServer окупятся. Еще несколько тестов, которые я сделал для хранилища данных Google App Engine: dbaspects.blogspot.com

person David Gruzman    schedule 29.01.2010