ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Просьба оценить производительность данной системы
22 сообщений из 22, страница 1 из 1
Просьба оценить производительность данной системы
    #37257068
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
Добрый день,
предлагается некое самодельное ядро СУБД. Есть нижеследующий тест вставки и запросов.
Может кто-нибудь оценить, как эти результаты соотносятся с производительностью стандартных БД?

Structure of testing table::
11 columns, 11 indexes:
char 11, long, char 33, char 3, double, char 111, long, long, char 11, long, double
Random data generation.

Time per record inclusive update of all indexes. Inserting with 1000 records-chunks.
Fully clearing all buffers after storage of every records-chunk.

0 - 700.000 records 0.2 - 5,5 ms
700.000 - 1.922.567 records 5,5 - 9,8 ms

Adding 100.000 recs to table with 2.234.011 recs - average time 10,1 ms/rec
Table with 2.334.011 records - total file(s) size 850 MB. Raw data size of this table is 201*2.234.011 = approx. 428 MB.
Table with ~ 11 Mio records - inserting time ~38 ms/rec.

Query execution ~5 Mio recs.
Query:
column generated data-span filter
0 (a - f), (k - r)
1 0 - 10 (0 - 4) (6 - 8)
2 (bababab - rarar), (sa - x)
6 0 - 300000000 (0 - 30000), (77777 - 9999999)
7 0 - 1000 (0 - 500)

Time till all rec-ids retrieved: 4,5 sec
...
Рейтинг: 0 / 0
12.05.2011, 14:42
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37257149
Как бэ в теме
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как бэ в теме
Гость
TJ7 явно выигрывает. Так что, незачет.
...
Рейтинг: 0 / 0
12.05.2011, 15:01
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37257340
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
dsrsman, вот тут винчестер тестировали, тоже очень неплохая производительность была
...
Рейтинг: 0 / 0
12.05.2011, 16:04
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37257363
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
SergSuper,

все смеетесь..
все равно на флешку медленно..
...
Рейтинг: 0 / 0
12.05.2011, 16:10
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37257376
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
dsrsman, ну а кому нужна СУБД без тщательного тестирования? одно дело какую игрушку написать, а тут вещь таки серьезная и даже если дикая производительность, но нет уверенности в надежности - мало кого заинтересует

собственно Вы тут не первый с этой утопичной идеей, скорее всего и не последний
...
Рейтинг: 0 / 0
12.05.2011, 16:18
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37257434
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
SergSuper,

я с вами согласен. Я неправильно выразился, в общем ничего не предлагается, а есть просьба оценить параметры, и все.
...
Рейтинг: 0 / 0
12.05.2011, 16:40
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37258002
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
dsrsman> average time 10,1 ms/rec

100 записей в секунду это ооочень медленно. Индексы правда мешаются.

Ориентир 1000-10000/сек
...
Рейтинг: 0 / 0
12.05.2011, 21:42
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37258005
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
SiemarglОриентир 1000-10000/сек 10000-100000/сек
...
Рейтинг: 0 / 0
12.05.2011, 21:46
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37274984
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
Спасибо всем кто отозвался. Хочу отметить, меня не интересует скорость при условии засоса всей базы в память. Провел тест сам. СУБД - SQL Server 2008.
Такая же таблица, индекс по каждому столбцу. Локальный сервер, один юзер.
Аутокоммит офф, коммит каждые 1000 записей. Вставил 4 милл. записей. Перезапустил сервис, память очистилась.
Теперь собственно тест.
Вставка 20тыс. записей:
Время - сначала 110 миллисек на запись, по мере заполнения памяти упала до 55 мсек. Т.е. в среднем 72 мс (14 записей в секунду). Могу смело утверждать, что с ростом БД будет намного медленнее.

Простой запрос по 4 столбцам - 16-20 сек.
...
Рейтинг: 0 / 0
23.05.2011, 17:17
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275027
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
интересно что у вас за железяка?
у меня не новый 2-х ядерный нотебук 2.2 Г, поставил сервер Microsoft SQL Server 2008 Express, ничего не настраивал
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
drop table #t
go
create table #t(a int, b int, c int, d int)

create index aa on #t(a)
create index bb on #t(b)
create index dd on #t(c)
create index ee on #t(d)
go
set nocount on
declare @i int, @d datetime

select @i= 0 , @d=GETDATE()

begin tran
while @i< 100000 
begin
	insert #t select RAND()* 1000 , RAND()* 1000 , RAND()* 1000 , RAND()* 1000 
	set @i=@i+ 1 
	if @i %  1000  =  0  
		begin
		commit tran
		begin tran
		end
end
commit tran

select DATEDIFF(ms, @d, getdate())
Код: plaintext
1.
-----------
4276

т.е. 100 000 (а не 20 000) вставилось за 4 сек
...
Рейтинг: 0 / 0
23.05.2011, 17:39
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275109
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andsm
Участник
SergSuper,

Сравнение неверное. Таблицы в tempdb иначе себя ведут - транзакции не ждут подтверждения физической записи на диск, в отличие от таблиц в обычных БД
...
Рейтинг: 0 / 0
23.05.2011, 18:12
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275145
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
SergSuper,

не в железяке дело. Он держит все в памяти, пока влазит и пока может.
...
Рейтинг: 0 / 0
23.05.2011, 18:25
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275174
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
dsrsman,

доступ к диску - еденицы миллисекунд. А сколько блоков нужно прочитать, чтобы обновить 10 индексов для тысячи записей в многомиллионной базе? Чудес не бывает.
...
Рейтинг: 0 / 0
23.05.2011, 18:39
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275185
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
SergSuper,

прикиньте, сколько записей 4х int влезет в память Вашего ноутбука.
...
Рейтинг: 0 / 0
23.05.2011, 18:45
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275190
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andsm
Участник
dsrsmanSergSuper,

не в железяке дело. Он держит все в памяти, пока влазит и пока может.

SQL Server пишет информацию об изменения в лог транзакций сразу, не кеширует ее в памяти. Более того - перед тем как сообщить о том что транзакция подтверждена, он дожидается окончания физической записи в лог.
...
Рейтинг: 0 / 0
23.05.2011, 18:48
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275197
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andsm
Участник
dsrsmandsrsman,

доступ к диску - еденицы миллисекунд. А сколько блоков нужно прочитать, чтобы обновить 10 индексов для тысячи записей в многомиллионной базе? Чудес не бывает.

10 индексов для тысячи записей в таблице с несколькими миллионами записей?
Если предположить что индексы по полю типа int, то ответ - примерно 20 000 - 40 000 страниц данных.
Ничего особенного.
...
Рейтинг: 0 / 0
23.05.2011, 18:51
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275213
dsrsman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dsrsman
Гость
andsmdsrsmandsrsman,

доступ к диску - еденицы миллисекунд. А сколько блоков нужно прочитать, чтобы обновить 10 индексов для тысячи записей в многомиллионной базе? Чудес не бывает.

10 индексов для тысячи записей в таблице с несколькими миллионами записей?
Если предположить что индексы по полю типа int, то ответ - примерно 20 000 - 40 000 страниц данных.
Ничего особенного.
Ну и сколько времени займет прочитать 20-40 тыс. страниц?
...
Рейтинг: 0 / 0
23.05.2011, 18:58
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275326
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
dsrsmanSergSuper,

не в железяке дело. Он держит все в памяти, пока влазит и пока может.да нет, tempdb обычная база с этой точки зрения, Вы наверное путаете с таблицами-переменными
сделал в обычной таблице, стало 10 сек для 100 000
дольше скорее из-за того что база увеличивалась

слушайте, я ничего не собираюсь доказывать, просто мне показались странными Ваши цифры и я решил проверить, смотрите результаты и сами выводы делайте
могу только посоветовать вместо изобретения велосипедов почитать что-нибудь полезное
...
Рейтинг: 0 / 0
23.05.2011, 20:16
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275620
MS-SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS-SQL
Гость
andsmSergSuper,

Сравнение неверное. Таблицы в tempdb иначе себя ведут - транзакции не ждут подтверждения физической записи на диск, в отличие от таблиц в обычных БД
в tempdb ждут подтверждения физической записи
...
Рейтинг: 0 / 0
24.05.2011, 00:04
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275650
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
MS-SQLв tempdb ждут подтверждения физической записи
А зачем?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
24.05.2011, 00:43
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37275662
MS-SQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS-SQL
Гость
Dimitry SibiryakovMS-SQLв tempdb ждут подтверждения физической записи
А зачем?

Мне это тоже интересно, но факт.
...
Рейтинг: 0 / 0
24.05.2011, 01:12
| Ответить | Цитировать | Написать  
Просьба оценить производительность данной системы
    #37278376
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andsm
Участник
MS-SQLandsmSergSuper,

Сравнение неверное. Таблицы в tempdb иначе себя ведут - транзакции не ждут подтверждения физической записи на диск, в отличие от таблиц в обычных БД
в tempdb ждут подтверждения физической записи
Создайте таблицу в обычной БД, затем вставьте в нее в цикле несколько тысяч записей. Замерьте время.
Затем тоже самое для tempdb. Разница будет в несколько раз.

То что транзакции в tempdb не ждут подтверждения физической записи на диск, вообще-то еще и много где описано.
...
Рейтинг: 0 / 0
25.05.2011, 13:14
| Ответить | Цитировать | Написать  
22 сообщений из 22, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Просьба оценить производительность данной системы
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=37258002&tid=1552680]:
 0ms
get settings:
 12ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 38ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 61ms
get tp. blocked users:
 2ms
others: 245ms
total:  394ms
созд. / загр.: 394ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]