Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
Приветствую всех участников форума!

У меня назрел такой вопрос. Есть простая табличка из двух полей
ID тип int
Name тип varcar(30)

Так вот суть вопроса, какая из СУБД справиться с этой задачей быстрее. Запрос к таблице такого рода SELECT * FROM tbl WHERE name='Что то'.
Тачка, на которой это будет - Pentium D, SCSI RAID 1 (miror, причем программный). Операционная система - что-нибудь из никсов. Плотность запросов ~30000-50000 в секунду. Размер таблицы 3 млн. записей. Размер порядка 200 мегабайт.
Есть одно но. СУБД должна быть бесплатно, хоть оракл, но бесплатный, его ограничений по размеру базы должно хватить. Конечно, ограничение по процессору и памяти не радуют, но всё же.

И сразу второй вопрос, кто имел дело с бесплатным ораклом? Какие его плюсы и насколько он урезан по сравнению с нормальным ораклом.

Я бы мог протестить всё самостоятельно, но хотелось бы узнать в каком ключе двигаться и что тестить(не тратить же время на тестирование всех СУБД, к сожалению время не позволяет). Кроме того, практика всегда отличается от тестов, поэтому рад буду выслушать все ваши мнения.
8 окт 06, 19:18    [3234563]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Thats right!
Приветствую всех участников форума!

У меня назрел такой вопрос. Есть простая табличка из двух полей
ID тип int
Name тип varcar(30)

Так вот суть вопроса, какая из СУБД справиться с этой задачей быстрее. Запрос к таблице такого рода SELECT * FROM tbl WHERE name='Что то'.
Тачка, на которой это будет - Pentium D, SCSI RAID 1 (miror, причем программный). Операционная система - что-нибудь из никсов. Плотность запросов ~30000-50000 в секунду. Размер таблицы 3 млн. записей. Размер порядка 200 мегабайт.

На однопроцессорной машине - никакая.
8 окт 06, 19:32    [3234603]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
PENTIUM D - у него два ядра, следовательно два проца.
Или и это не хватит? Тогда вопрос. как можно разрулить кластер на двух тачках похожей конфигурации?
8 окт 06, 19:38    [3234624]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Thats right!
Запрос к таблице такого рода SELECT * FROM tbl WHERE name='Что то'.

Для такого вида запросов в таком количестве голая СУБД - не лучший выбор, слишком много лишнего навешано. Лучше закешировать эти 200 мегов в памяти, в хэше/массиве/итп и выдавать без всяких селектов.

На тему бесплатного оракла.... скажем так, ничего существенного с точки зрения описанной задачи там не отрезано.
8 окт 06, 20:26    [3234715]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
softwarer
Thats right!
Запрос к таблице такого рода SELECT * FROM tbl WHERE name='Что то'.

Для такого вида запросов в таком количестве голая СУБД - не лучший выбор, слишком много лишнего навешано. Лучше закешировать эти 200 мегов в памяти, в хэше/массиве/итп и выдавать без всяких селектов.


Просто можно было кешить всё на "клиенском" приложении, но проблема в том, что с этой базой работают несколько независимых серверов, а писать синхронизацию всего этого добра.... Неужели на уровне СУБД нельзя такое обеспечить?
8 окт 06, 20:42    [3234730]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
Thats right!
Просто можно было кешить всё на "клиенском" приложении,

Я бы скорее приписал что-нибудь сбоку, не сервер приложений, а просто "небольшой сервер ответа вот на этот персональный вопрос". И пусть все спрашивают именно у него, а он будет возвращать данные из кэша и слушать оповещения БД об изменении данных.

Thats right!
Неужели на уровне СУБД нельзя такое обеспечить?

Можно. Но при этом я бы ожидал потерь в производительности. Насколько заметных - не готов сходу оценить. По идее, самыми быстрыми в этом случае должны быть in-memory databases, затем - обычные из расчета "чем проще, тем лучше".

Но с чем сравниваем - сравниваем с примерно мегабайтным массивом указателей на строки, для которого мы можем выбрать логику хранения/доступа исходя из особенностей данных (скажем, если id непрерывные, будет обычный индексированный массив - скорость выборки просто непревзойденная).
8 окт 06, 21:02    [3234746]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19923
Пару лет назад на двухпроцессорной машине с oracle 9i удавалось получить похожий рейт.
Условия теста похожи - около 8 млн. записей, обращения по первичному ключу.
Пул сессий был что-то около трех десятков, вся таблица была полностью поднята в buffer cache.
8 окт 06, 23:47    [3234973]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Funny_Falcon
Member

Откуда:
Сообщений: 447
andrey_anonymous
Пару лет назад на двухпроцессорной машине с oracle 9i удавалось получить похожий рейт.
Условия теста похожи - около 8 млн. записей, обращения по первичному ключу.
Пул сессий был что-то около трех десятков, вся таблица была полностью поднята в buffer cache.

30000-50000 в секунду? А сколько типичное кол-во выбираемых строчек? Если 1-4, то могу поверить.
9 окт 06, 10:51    [3235714]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
Funny_Falcon
andrey_anonymous
Пару лет назад на двухпроцессорной машине с oracle 9i удавалось получить похожий рейт.
Условия теста похожи - около 8 млн. записей, обращения по первичному ключу.
Пул сессий был что-то около трех десятков, вся таблица была полностью поднята в buffer cache.

30000-50000 в секунду? А сколько типичное кол-во выбираемых строчек? Если 1-4, то могу поверить.


Суть проста, надо выбрать ID слова и всё, количество возвращаемых записе - одна, так как слова в поле Name уникальны.

А если тип HEAP в мускуле для этой цели использовать? И если как вариант подойдет, то как лучше сбрасывать данные из HEAP в Innobd например, как лучше провести синхронизацию? Есть у кого-нибудь подобная практика?
9 окт 06, 11:05    [3235811]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Thats right!
Funny_Falcon
andrey_anonymous
Пару лет назад на двухпроцессорной машине с oracle 9i удавалось получить похожий рейт.
Условия теста похожи - около 8 млн. записей, обращения по первичному ключу.
Пул сессий был что-то около трех десятков, вся таблица была полностью поднята в buffer cache.

30000-50000 в секунду? А сколько типичное кол-во выбираемых строчек? Если 1-4, то могу поверить.


Суть проста, надо выбрать ID слова и всё, количество возвращаемых записе - одна, так как слова в поле Name уникальны.

А если тип HEAP в мускуле для этой цели использовать? И если как вариант подойдет, то как лучше сбрасывать данные из HEAP в Innobd например, как лучше провести синхронизацию? Есть у кого-нибудь подобная практика?
Можно попробовать MySQL cluster поднять. он затаскивает всю БД в память и оперирует in-memory.

Может быть и вытянет.
+ это транзакционный движок и не нужно мучаться со "сбрасывать данные из HEAP в Innobd", т.к. сохраняет данные/логи на винте.
НО cluster предназначен для "постоянной доступности" данных, и скорость не основной его плюс.

Нужно тестить в общем.
ЗЫ а действительно нужно 30к - 50к запросов в сек НА ОДИН сервер. Возможно достаточно будет поднять несколько СУБД разгрузив их, связать через один мастер - много подчиненных. Управление и наполнение идет через мастера, запросы на подчиненных.
9 окт 06, 11:24    [3235924]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Thats right!

Суть проста, надо выбрать ID слова и всё, количество возвращаемых записе - одна, так как слова в поле Name уникальны.

Ну тогда не нужен Вам никакой SQL. Берете например GT.M и весь Ваш запрос превращается в один оператор
s ID=$g(^TABLE(name))
При указанном объеме оперативки на сервере поставить гиг, база вся ляжет в кэш, и летать будет, никто не догонит :-)
9 окт 06, 11:32    [3235976]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
MX -- ALEX
Guest
LittleCat
Thats right!

Суть проста, надо выбрать ID слова и всё, количество возвращаемых записе - одна, так как слова в поле Name уникальны.

Ну тогда не нужен Вам никакой SQL. Берете например GT.M и весь Ваш запрос превращается в один оператор
s ID=$g(^TABLE(name))
При указанном объеме оперативки на сервере поставить гиг, база вся ляжет в кэш, и летать будет, никто не догонит :-)


также годится MSM, CACHE, - платные
M3-LITE - бесплатная

принцип тот же что и GT.M

но все под Windows
GT.M - под LINUX
в любом варианте летать будет на 220 %
9 окт 06, 12:23    [3236380]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
Хм... А GT.M под линукс не бесплатная? И как с ней работать из с++?
9 окт 06, 12:57    [3236639]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Thats right!
Хм... А GT.M под линукс не бесплатная? И как с ней работать из с++?

Под Linux как раз GT.M бесплатный, и исходники на sourceforge лежат :-) А как работать из С++, это уже дело вкуса, вариантов много, нужно доку читать...
9 окт 06, 13:10    [3236746]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
GTM_UNIX-Prog-Manual-4.4.pdf глава 11 раздел Calls from External Routines: Call-Ins
9 окт 06, 13:26    [3236847]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
LittleCat
Thats right!
Хм... А GT.M под линукс не бесплатная? И как с ней работать из с++?

Под Linux как раз GT.M бесплатный, и исходники на sourceforge лежат :-) А как работать из С++, это уже дело вкуса, вариантов много, нужно доку читать...


Уже скачал, просто супер(я про форум, GM.T пока не юзал, ибо только скачал). Тогда такой вопрос, просто я не разу не работал с нереляционными базами данных, но давно искал инфу о них, так вот вопрос.
Могут ли нереляционные базы данных выполнять запросы аналогичные запросам с LEFT JOIN'ом в мускуле? И насколько это быстрее работает чем в мускуле. вообщем выборка что то вроде SELECT * FROM tbl AS tbl1 LEFT JOIN tbl AS tbl2 ON tbl1.id_name=tbl2.id_name WHERE tbl1.id_name1='25' and tbl2.id_name1='23'. Вообщем суть в том, что выборка идет из одной таблицы, но с извращением:)
9 окт 06, 14:17    [3237143]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Thats right!
Вообщем суть в том, что выборка идет из одной таблицы, но с извращением:)

Ну так тоже не страшно, сделаем индексацию в том же глобале, вот пример создания одной записи (при условии что ID и name не пересекаются)
s ^TABLE(name)=ID,^TABLE(ID)=name
Ну а дальше выборка
 if ^TABLE(23)=^TABLE(25) w !,"Found ",^TABLE(23) 
Результат тоже будет мгновенный :-)
9 окт 06, 16:02    [3237859]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
LittleCat
Результат тоже будет мгновенный :-)


Тогда вопрос, как говорится, на засыпку. Как поведет себя GT.M на базе размером в 20 гиг , где количество записей от 200 млн. на той же тачке, о которой я говорил в первом посте. Запросов разумеется гораздо меньше, макс ~3 в секунду.
9 окт 06, 17:26    [3238445]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Thats right!

Тогда вопрос, как говорится, на засыпку. Как поведет себя GT.M на базе размером в 20 гиг , где количество записей от 200 млн. на той же тачке, о которой я говорил в первом посте. Запросов разумеется гораздо меньше, макс ~3 в секунду.

ИМХО без проблем, если учесть, что на нем строят банковские системы и системы автоматизации крупных госпиталей. Есть подозрение, что и 200 гиг не будут проблемой....
PS С бОльшей уверенностью рекомендовал бы Cache, но вопрос был про бесплатную базу ;-)
9 окт 06, 17:45    [3238552]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
LittleCat, а вы можете сбросить кусок кода готовой программы, мне кжется так будет легче разобраться :). Маленький примерчик ;)
9 окт 06, 19:32    [3238997]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
А транзакции поддерживать надо или нет? Если не надо - просто строиться хэш-таблица в оперативной памяти, и вся любовь. СУБД при таком раскладе просто не нужна, лишние "тормоза".
9 окт 06, 19:34    [3239000]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Thats right!
LittleCat, а вы можете сбросить кусок кода готовой программы, мне кжется так будет легче разобраться :). Маленький примерчик ;)

Пардон, не понял, примерчик чего ? Если я знаю о каком-то механизме взаимодествия с базой данных, это еще не значит, что я использовал его в своей работе ;-) Для Вашей специфичной задачи я бы сделал прямой доступ через функции, экспортируемые libgtmshr.so, что дало бы выигрыш в скорости по сравнению с методами, рекомендуемыми в документации, но это надо маленько поразбираться с внутренним устройством системы, что требует времени...
10 окт 06, 10:25    [3240091]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
Thats right!
Member

Откуда:
Сообщений: 10
LittleCat
Пардон, не понял, примерчик чего ?


Сори, я думал у вас был опыт работы с этой прогой. Просто хотелось посмотреть пример реализации какого нибудь алгоритма, чтобы на основе этого разбираться дальше. :) Спасибо за дельные советы. Буду пытаться "их прикрутить к проге"!
10 окт 06, 10:38    [3240176]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Thats right!
LittleCat
Пардон, не понял, примерчик чего ?


Сори, я думал у вас был опыт работы с этой прогой. Просто хотелось посмотреть пример реализации какого нибудь алгоритма, чтобы на основе этого разбираться дальше. :) Спасибо за дельные советы. Буду пытаться "их прикрутить к проге"!

Это не просто прога, это база данных, основанная на М-технологии, и в этой технологии у меня опыта больше 10 лет ;-) Ну и с GT.M, в частности, опыт имеется. Просто вопрос был слишком абстрактный, насчет примерчика. Во что превращается Ваш "хитрый" SQL запрос, я вроде показал, если спросите еще что-то конкретное, опять же могу попробовать помочь...
10 окт 06, 12:00    [3240835]     Ответить | Цитировать Сообщить модератору
 Re: Кто быстрее выполнит простой запрос  [new]
c127
Guest
Thats right!
LittleCat
Результат тоже будет мгновенный :-)


Тогда вопрос, как говорится, на засыпку. Как поведет себя GT.M на базе размером в 20 гиг , где количество записей от 200 млн. на той же тачке, о которой я говорил в первом посте. Запросов разумеется гораздо меньше, макс ~3 в секунду.


Вы все-таки на всякий случай протестируйте самостоятельно, тест несложный, а то тут насоветуют. 50000 запросов/сек у них будет летать в любом варианте на 220 процентов. Несерьезно. Причем обратите внимание, люди клянутся, что все будет работать, даже не узнав, какое у Вас сетевое оборудование. В интернете ж за базар отвечать не нужно.

А Вам потом отвечать перед начальством и клиентами, причем в реале.



Максимальное превосходство М-систем и Кеша перед РСУБД по скорости, которое нам тут продемонстрировали с очень многочисленными оговорками не дотягивало и до порядока, т.е. меньше чем в 10 раз. А вообще по-моему получалось раза в 2-3 быстрее, если не ошибаюсь и то повторить никому не удалось. Ну ладно, пусть будет М-система в 10 раз быстрее СКЛ сервера. 5000 транзакций/сек на СКЛ сервер на обычной машине в такой задаче это фантастика по-моему. Так что 50000 транзакций для М-системы это ИМХО трындеж чистой воды.

А 3 транзакции на 200 млн записей легко выдаст любой нормальный СКЛ сервер на нормальном кухонном железе.

По вопросу о 50000 транзакциях. Поставьте на сервер побольше мозгов, это дешево, напишите на С++ програмку, заведите там ассоциативный массив, заполняйте его в начале сессии. Подключите эту программу как плагин к веб серверу или кто у Вас обрабатывает запросы, или пусть сама слушает порты, и получите близкое к теоретическому быстродействие. Будет бесплатно и быстро, быстрее уже не получится. Как Вам тут уже говорили, непонятно зачем в этой задаче вообще нужны СУБД.
11 окт 06, 03:26    [3244835]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить