Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 9 10 [11]      все
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Тут Сергей постояно говорит:
обратите внимание, что идет последовательный перебор

И что это проблемы Каше и других М систем. Сделайте аналогичный SQL запрос если вам перебор не нравиться. Я думаю там вообще результат будет хуже раза в 2. В одном из топиков кто-то делал сравнение SQL в Оракле и Каше. Результат был не в пользу Каше раза в 1.5.

а вот не надо утверждать за меня, ладно? не надо путать "последовательный
перебор записей" и "работу с последовательными файлами". Cache действительно сильно подсаживает систему при работе с обычным файлом,
по крайней мере так в 5.0.11
перебор записей, лежащих в БД подряд,
в РСУБД будет быстрее, это однозначно.
с таким же успехом я могу утверждать, что простенькая программка на C круче обеих тестируемых СУБД, поскольку сделает все то же с обычным файлом намного быстрее. :)
24 май 06, 04:13    [2698635]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Sergei Obrastsov
c127

А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве.

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

вот ведь забавно. сколько раз уже объясняли, что при необходимости ввести
новый индекс он просто создается и все. и в SQL его надо создавать, и в M
его надо создавать. в SQL это менее затратно? согласен. за удобство
работы с данными нужно платить.

В который раз спрашиваю: в чем именно состоит удобство работы с данными? В том что программы в 3 раза длиннее? Так это скорее неудобство.

Потом индексы в КЕШ-е создаются медленнее, получается если создать-посмотреть аналитику-убить, то может получиться что займет больше времени. Правда и места больше.

Насколько быстрее МуСКЛ создает индекс? Не могли бы Вы привести цифры, у Вас же они оба на одной машине. А то по размерам файлов, где КЕШ выигрывает приводятся конкретные цифры, а по созданию индекса, где КЕШ проигрывает - только признание, что таки медленнее. Двойные стандарты получаются.


Sergei Obrastsov

c127

Sergei Obrastsov

а вот насчет дисков проблема, 80Gb - все,
что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :)

Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb.

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

Не нужно выжимать из меня слезу, мы не в церкви. Вы систему на 10 млн пользователей на этих дисках сертифицировали, или может предлагаете своим клиентам хранить работать с промышленными базами на 80Гб ИДЕ дисках с фат32? Так к чему эти разговоры о бедных? Экономить нужно там где это действительно дает экономию, а не покупать сервер БД за сотню тысяч, а потом экономить по 20 долларов на дисках. В любом случае 10Гб было бы дешевле, почему же Вы остановились на 80Гб, раз зарплата маленькая, экономили бы уже по полной.

Sergei Obrastsov

c127

Вы по-видимому просто не представляете себе что такое геометрическая поргрессия. Ей там неоткуда взяться, скорее всего Вы перепутали с арифметической прогрессией.

кол-во зарегистрированных сотовых телефонов в городе по годам:
2003  2004  2005-2006
0      1000   150000
как там будет выглядеть рост кол-ва звонков по ним?

Как арфиметическая прогрессия разумеется. Пусть каждый пользователь делает J звонков за интересующий нас период, тогда у одного пользователя будет
1*J звонков,
два пользователя - J+J звонков,
....
N пользователей - N*J звонков
N+1 пользователь - N*J+J звонков
....
То есть каждый следующий "на" J звонков больше предыдущего, а не "в" J раз, как это должно было бы быть в случае геометрической прогрессии. Еще раз повторяю, не растет база в геометрической прогрессии, неоткуда ей там взяться.

Sergei Obrastsov

я понимаю, что хочется "погнуть пальцы и постучать копытами". но может
лучше это делать не здесь?

Лучше выучить что такое арифметическая прогрессия, или же не использовать непонимаемые слова.

Sergei Obrastsov

c127

Sergei Obrastsov

эти вещи просьба мне в вину не ставить, SQL пакует числа, так
что нечего тут,
СКЛ числа не пакует.

пакует. в 2 байта, в 4 байта... для меня это упаковка.


Числа СКЛ сервером не пакуются, тут нечего обсуждать, а то получится как с геометрической прогрессией. Они хранятся в двух байтах, четырех, восьми и т.д. И что очень важно - как хранятся, так и обрабатываются, в этом же формате. Не тратит сервер времени на упаковку-распаковку, это родной формат современных процессоров. То что КЕШ поступает по-другому и хранит все в строках это его проблема и не повод чтобы весь мир под него подстраивался и менял систему понятий.




Sergei Obrastsov

v13 - заданный список
v14 - заданный список

Что такое заданный список?

Sergei Obrastsov

размер запросов не лимитирован, т.е. могут быть заданы все условия одновременно.

В таком случае говорить не о чем, нужны все индексы. Но ведь такого не бывает, обычно используется несколько процентов возможностей системы. У Вас ведь тоже нет всех индексов. Из всех Ваших запросов, которых по самым скромным оценкам не менее 2^13=8192, будут использоваться штук 10. Их нужно оптимизировать, остальные - пусть ждут, но скорее всего они никогда не встретятся.

Sergei Obrastsov

50% на 100Gb - существенная разница.

50% это и в африке 50%. Разница в цене диска долларов 10, если это сущестенно, то да, разница существенная. Но тогда нужно переходить на файерберд, он бесплатный, экономия на сервере БД.

Sergei Obrastsov
pgres
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

прокомментируйте плз

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

а вот "размер данного" - это да, система дольше читает.

Согласен, вывод противоречит законам физики. Поиск происходит даже если используется индекс. Если КЕШ использует древовидные индексы, то у них рост примерно O(log2(N)). Это немного, но заявлять что от количества даннных не зависит неверно.

А вот зависимость от размера данных очень подозрительна. Не строки ли, в которых хранит данные КЕШ в этом виноваты? Не должно заметно зависеть, если система не качает эти данные на клиент, а при выполнении запроса она их туда качать не должна, только результат.
24 май 06, 04:14    [2698636]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

Откуда:
Сообщений: 933
Sergei Obrastsov
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше

а по поводу 512М оперативки мы типа не заметим....
типа не критично...
;)
24 май 06, 05:36    [2698658]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
andy st
Sergei Obrastsov
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше

а по поводу 512М оперативки мы типа не заметим....
типа не критично...
;)


Вот имено для баз гораздо боле критичным ресурсом является объем оперативной памяти (так как больший объем позволяет избегать медленных дисковых операций за счет кеша) чем такторая частота процессора.
24 май 06, 05:42    [2698661]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
andy st
Sergei Obrastsov
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше

а по поводу 512М оперативки мы типа не заметим....
типа не критично...
;)


Вот имено для баз гораздо боле критичным ресурсом является объем оперативной памяти (так как больший объем позволяет избегать медленных дисковых операций за счет кеша) чем такторая частота процессора.

для Cache это не критично. она отгрызает свои там 80-100 метров на процессы
и дисковый кэш и все. говорят дескать увеличение дискового кэша дает прирост скорости... но на первом проходе все-равно нифига не дает.
сколько дисковый кэш был у меня? 16 метров, стандарт.
24 май 06, 07:31    [2698732]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

Откуда:
Сообщений: 933
Sergei Obrastsov
Joker_Ya
...
Вот имено для баз гораздо боле критичным ресурсом является объем оперативной памяти (так как больший объем позволяет избегать медленных дисковых операций за счет кеша) чем такторая частота процессора.

для Cache это не критично. она отгрызает свои там 80-100 метров на процессы
и дисковый кэш и все. говорят дескать увеличение дискового кэша дает прирост скорости... но на первом проходе все-равно нифига не дает.
сколько дисковый кэш был у меня? 16 метров, стандарт.


Sergei Obrastsov

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.

а про кеш windows тоже забудем.... )
особенно на 1 гиге оперативки
24 май 06, 07:53    [2698758]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
andy st
Sergei Obrastsov

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.

а про кеш windows тоже забудем.... )
особенно на 1 гиге оперативки

не забудем. и про выборку 100 раз тоже.
только вот разницы между первым прогоном и последующими нет.
ну, например, 60-62-62-61-62-60-60-62...
и от увеличения дискового кеша не меняется.
и от "kept in memory" тоже не меняется.
24 май 06, 08:46    [2698826]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

Откуда:
Сообщений: 933
Sergei Obrastsov

не забудем. и про выборку 100 раз тоже.
только вот разницы между первым прогоном и последующими нет.
ну, например, 60-62-62-61-62-60-60-62...
и от увеличения дискового кеша не меняется.
и от "kept in memory" тоже не меняется.

а перед тестами все кеши, в т.ч. и виндовый, были сброшены ??
и вопрос 2:
как будет вести себя Cache, если в момент создания отчета будет происходить правка исходных данных?
24 май 06, 09:02    [2698854]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
24 май 06, 09:20    [2698924]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Sergei Obrastsov

сколько дисковый кэш был у меня? 16 метров, стандарт.


Вот потому то и получилось так медленно. 16 - это недопустимо мало для миллионов записей. Я просил Вас проверить программку, подозревая что у Вас маленький кэш. Ну а теперь и так ясно.

Увеличьте кэш до 200, хотя бы, и проверьте что выйдет с вашим тестом. Очень это интересно.
24 май 06, 11:07    [2699459]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura1976
Guest
Мои соображения.

У меня дома сейчас стоит SQL 2005 Express.
Недавно получил обещаный диск от Cache 5 (однопользовательский).
Базы данных будут расположены на FAT 32
Все настройки по дефолту

Комп P3 chipset 815 Hard 160 GB RAM 512 MB

Готов установить cahce 5 и провести тест

Пожалуйста, cache-исты подскажите мне прогу которая создает таблицу на 45 000 000 записей и заполянет ее случайными данными)

данные для таблицы
{
id_row int,
a_phone varchar(32)
b_phone varchar(32)
originating datetime
terminatin datetime
duration int
base_station_id int
disconnect_reason smallint
}

три некластерных индекса

a_phone
originating
base_station_id

Пожалуйста, подскажите, как потом те же данные перенести с Cache на SQL 2005 express.

Предложите процедуры сравнения для
1. SELECT - 3 разных запроса
2. INSERT - 2 разных запроса
3. UPDATE - 2 разных запроса
4. DELETE - 2 разных запроса.

Я постараюсь максимально не предвзято провести сравнение
24 май 06, 12:25    [2699943]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>Недавно получил обещаный диск от Cache 5 (однопользовательский).

Если у Вас нет лицензии, сравнения будут бессмысленны. Вам лучше обратиться в InterSystems за временной лицензией. Обьясните ситуацию и попросите временную лицензию.
24 май 06, 12:48    [2700095]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura1976
Guest
yww@escape.ru
>>Недавно получил обещаный диск от Cache 5 (однопользовательский).

Если у Вас нет лицензии, сравнения будут бессмысленны. Вам лучше обратиться в InterSystems за временной лицензией. Обьясните ситуацию и попросите временную лицензию.


Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
24 май 06, 14:23    [2700680]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
в однопользовательском режиме бстрее всего будут работать dbf файлы :)
--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
24 май 06, 14:47    [2700845]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Iura1976
Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять...
24 май 06, 14:47    [2700848]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?
24 май 06, 14:55    [2700908]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
version
Guest
pavelvp
Iura1976
Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять...


https://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su?
24 май 06, 14:56    [2700917]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
version2
Guest
version
pavelvp
Iura1976
Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять...


https://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su?


sorry,
https://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su�
24 май 06, 14:57    [2700925]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
version3
Guest
не проходит правильная ссылка...

"Именно. У версии, которая SU, кеш ограничен."
24 май 06, 15:00    [2700949]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov
pgres
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?


я перестал Вас понимать
объясните к чему это
24 май 06, 15:05    [2700978]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
Sergei Obrastsov
pgres
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?


я перестал Вас понимать
объясните к чему это

уф... я же сказал, что рассчитывал значение времени в часах по КАЖДОЙ строке. потом указал, что пересчет с учетом этого изменения,
по первой структуре занимает 60-62 сек.
сейчас вот пересчитал по второй - 71-72

размер кеш значения не имеет. что 16 метров, что 200 - однофигово.
это и очевидно, слишком большой объем данных.
24 май 06, 15:58    [2701370]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
Sergei Obrastsov
pgres
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?


я перестал Вас понимать
объясните к чему это

уф... я же сказал, что рассчитывал значение времени в часах по КАЖДОЙ строке. потом указал, что пересчет с учетом этого изменения,
по первой структуре занимает 60-62 сек.
сейчас вот пересчитал по второй - 71-72

размер кеш значения не имеет. что 16 метров, что 200 - однофигово.
это и очевидно, слишком большой объем данных.
24 май 06, 16:10    [2701441]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 Sergei Obrastsov

Да пожалуйста провел я дефрагментацию индекса.
работает 68 сек
и я настаиваю что никакого превосходства каше над рдбмс нет - будь у меня гиг памяти будет работать еще на 40% , быстрее

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
25 май 06, 10:36    [2703994]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 9 10 [11]      все
Все форумы / Сравнение СУБД Ответить