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

Откуда:
Сообщений: 3652
ну я
+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0.
USER>w +"abc"
0
USER>w +"123abc"
123
USER>w +"123e3abc"
123000
USER>w +"123.98abc"
123.98
USER>w +"++--+-123"
-123

USER>w +"123"
USER>w +"0123"
USER>w +"00000123"
выдадут одинаковый результат?
если да, то считаются ли эти строки ("123", "0123" и "00000123") равными? в частности при записи в эту... как её... в глобаль?

Документация ставится при установке, также есть онлайн
тынц

сенкс, на досуге поизучаю.
18 май 06, 21:26    [2681382]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Пьяный Лох
ну я
+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0.
USER>w +"abc"
0
USER>w +"123abc"
123
USER>w +"123e3abc"
123000
USER>w +"123.98abc"
123.98
USER>w +"++--+-123"
-123

USER>w +"123"
USER>w +"0123"
USER>w +"00000123"
выдадут одинаковый результат?

Да.

Пьяный Лох
если да, то считаются ли эти строки ("123", "0123" и "00000123") равными? в частности при записи в эту... как её... в глобаль?

Нет, лидирующий ноль - неканоничен.
18 май 06, 22:43    [2681579]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Пьяный Лох
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.

А ведь есть еще даты.
19 май 06, 00:29    [2681858]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
c127
Пьяный Лох
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.

А ведь есть еще даты.

не будем о грустном
19 май 06, 00:40    [2681897]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
c127
Пьяный Лох
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.

А ведь есть еще даты.

не будем о грустном

а что с ними такого страшного? нет, конечно, можно и хранить их в виде
dd.mm.gggg, но это неудобно. обычно пользуются их машинным
форматом, т.е. 19.05.2006 = 60404. аналогично для времени
19 май 06, 01:13    [2681985]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Sergei Obrastsov
c127
Деревья не изобретение КЕШ-а. Запатентуйте еще блок питания и постоянный ток.
Данные в РСУБД (по-видимому это они понимаются под именем "современные базы данных") хранятся в таблицах, которые есть отношения. Как было у Кодда в самом начале, так и осталось, никто никуда не пришел. А индексы - это средство, вопрос удобства и вряд ли их взяли из КЕШ-а.

Cache здесь, честно говоря, вообще не причем. речь идет о M-технологии.

Речь идет как раз о КЕШ-е, которая, если не ошибаюсь, построена на М.

Sergei Obrastsov

ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как
видим, они оказались дальновидны. а ведь все очень просто, с большими
объемами данных первыми столкнулись именно они.

Как же, знаем, они также первыми высадились на берега Америки, еще до викингов. А ссылочку не приведете на большие объемы данных?


Sergei Obrastsov


Не приходится. На устройстве прямого доступа можно перейти на заданный сектор (страницу) без прохода по промежуточным. Это Вы перепутали с ленточным устройством, которое последовательного доступа. Ненужные данные читаются всегда, существует минимальная порция считывания с диска, сектор по-моему, меньше него железо прочитать физически не в состоянии. Но ненужные сектора не читаются, даже если они принадлежат тому же файлу.

приходится. над физическое размещение файла наложена его логическая
структура, которая ну никак в секторы по 512 байт не укладывается.
об этом Вам и говорят. вот тот же блок в 8Kb, например.

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

Sergei Obrastsov


Iura

Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию.

Не кучу, гораздо меньше чем данные, но безусловно занимают. А что, в КЕШ-е индексы места вообще не занимают? Иерархия деревьев в КЕШ-е тоже сложная.
Мы выяснили в соседнем топике что в М, например, индексы отсутсвуют в принципе. Вместо них предлагается ДУБЛИРОВАТЬ ДАННЫЕ в деревья подходящей структуры. Вот это действительно КУЧА места. Место под индексы по сравнению с этим - детские шалости.

как мы уже заметили в "соседнем топике", наличие этого дублирования
почему-то не занимает КУЧУ места, а занимает объем гораздо меньший,
чем прекрасно организованные индексы в SQL. можем повторить опыт,
если есть желание. :)

Мы этого к сожалению не заметили. Приведите ссылку, где это обсуждалось и где выяснилось, что так называемые индексы в М не занимают кучу места.

Дублирование данных (индексирование по-Вашему) обсуждалось тут:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070
от слов "В предположении, что индекса по пассажирам нет" и дальше по топику

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

Sergei Obrastsov

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

К Вашему сведению позиционирование головки от размера файла никак не зависит. Диск крутится все время, ОС елозит головками по диску все время, поэтому совершенно неизвестно где окажется головка по отношению к следующему запрашиваемому сектору.


Sergei Obrastsov

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

Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся.
А, вот нашел, оказывается есть дефрагментатор для ext2, но:
"ext2fs is somewhat resilient against fragmentation, and more importantly is not severely affected by it when it does happen.
This is quite different from the "MS-DOS experience," where fragmentation has significant deleterious effects on system performance."
http://cbbrowne.com/info/defrag.html
Но при чем тут дефрагментация?

Ну ладно, хотите чтобы зависело, пусть зависит. Но повторяю в третий раз: РАЗМЕР БД ПРИ ОБЫЧНОЙ РАБОТЕ (не специальные тесты) РАСТЕТ НЕ БЫСТРО И ПУСТЫХ МЕСТ ТАМ ОБЫЧНО НЕ СИЛЬНО МНОГО. Объяснял почему, можно еще книжки почитать для разнообразия. Это закрывает вопрос о больших файлах, даже в том случае, если скорость на них и падает.
19 май 06, 01:45    [2681993]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
интересно...
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?
2. Если для всех математических вычислений приходится производить конвертацию каждого аргумента к числовому виду (если это возможно, конечно), то вряд ли можно получить выигрыш по скорости.
3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных?
19 май 06, 02:22    [2682010]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
AAron
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?

.3333333333333333333
так и хранится, как строка. если тебя интересует как это обрабатывает
модуль вычислений - понятия не имею.


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

по сравнению с компилятором? конечно же нет. а никто и не утверждал
обратного.


3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных?

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

С уважением. Сергей
19 май 06, 02:33    [2682014]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Sergei Obrastsov
AAron
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?

.3333333333333333333
так и хранится, как строка. если тебя интересует как это обрабатывает
модуль вычислений - понятия не имею.

гм... и сколько знаков? SQL Server способен в типе данных float занимая 8 байт хранить следующее (msdn)
Floating precision number data with the following valid values: -1.79E + 308 through -2.23E - 308, 0 and 2.23E + 308 through 1.79E + 308.


Sergei Obrastsov


3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных?

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

"в 3." - не понял, это к третьему пункту или в три раза? Мне вообще не хочется хранить упакованные или неупакованные числа в виде строк.
А в базах данных числа в том числе хранятся.
Например, банк заключает сделки на бирже. типичный набор полей таблицы (trade_id int, asset_id int, currency_id int, deal_date datetime, price float, quantity float). Итого - ни одной строки, но масса чисел.

Другой пример. Телеком. Информация о звонках в системе. Таблица (call_date datetime, circuit_id int, prefix_id int, client_id int, host_id int, seconds_1 int, seconds_2 int, amount_1 int, amount_2 int) ну и т.д.
Таблицы разумеется более сложно структуры, но суть отражают. Количество записей - для банков (россии) это сотни тысяч, для телекома - миллионы.
19 май 06, 03:01    [2682027]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186

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

С уважением. Сергей


А что по вашему в основном храниться в БД строки ? Большенство баз в мире имеет отношение к финансовой и производственной деятельности. В них храняться показатели данных сфер деятельности (деньги, количество). Имено с ними и приходиться выполнять такие операции как например суммирование или сложение и вычитание. При больших объемах данных перевод строк в числа и обратно процедура настолько затратная что обещание фантастических скоростей при использовании MUMPS сомнительно. Что в общем то и подтвердилось у нас. Скорость расчетов на M ситеме оказалась намного меньше чем в том же ORACLE. Чудес не бывает. Не может тот же PHP (который так же использует нетипизированные пременные и является как и MUMPS интерпритатором обогнать в скорости вычислений программу на С). Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз.
19 май 06, 03:15    [2682031]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

Sergei Obrastsov

ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как
видим, они оказались дальновидны. а ведь все очень просто, с большими
объемами данных первыми столкнулись именно они.

Как же, знаем, они также первыми высадились на берега Америки, еще до викингов. А ссылочку не приведете на большие объемы данных?

а сами объемы не нужно привести? Mumps создавался для системы здравоохранения, по-моему можно прикинуть количество данных,
которые там крутятся
(если честно, я притомился искать в инете конкретные цифры)


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

а разве я говорил про полное чтение файла? речь, скажем, о чтении индексного дерева, которое явно читается не по секторам.



как мы уже заметили в "соседнем топике", наличие этого дублирования
почему-то не занимает КУЧУ места, а занимает объем гораздо меньший,
чем прекрасно организованные индексы в SQL. можем повторить опыт,
если есть желание. :)

Мы этого к сожалению не заметили. Приведите ссылку, где это обсуждалось и где выяснилось, что так называемые индексы в М не занимают кучу места.

Дублирование данных (индексирование по-Вашему) обсуждалось тут:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070
от слов "В предположении, что индекса по пассажирам нет" и дальше по топику


https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383
еще раз скажу, что сравнивалась SQL (MySQL, MSSQL) таблица с одним индексом и Cache-структура с 9-ю.


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

я только ЗА. ссылки приведены.


Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся.

я бы рад избавиться, но пока приходится дефрагментировать. не часто и все же. про ext2 ничего не скажу, мне приходится работать под Windows
19 май 06, 03:51    [2682041]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
AAron
Sergei Obrastsov
AAron
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?

.3333333333333333333
так и хранится, как строка. если тебя интересует как это обрабатывает
модуль вычислений - понятия не имею.

гм... и сколько знаков? SQL Server способен в типе данных float занимая 8 байт хранить следующее (msdn)
Floating precision number data with the following valid values: -1.79E + 308 through -2.23E - 308, 0 and 2.23E + 308 through 1.79E + 308.

18
впечатляет. но пока хватает и 18.


"в 3." - не понял, это к третьему пункту или в три раза? Мне вообще не хочется хранить упакованные или неупакованные числа в виде строк.
А в базах данных числа в том числе хранятся.
Например, банк заключает сделки на бирже. типичный набор полей таблицы (trade_id int, asset_id int, currency_id int, deal_date datetime, price float, quantity float). Итого - ни одной строки, но масса чисел.

Другой пример. Телеком. Информация о звонках в системе. Таблица (call_date datetime, circuit_id int, prefix_id int, client_id int, host_id int, seconds_1 int, seconds_2 int, amount_1 int, amount_2 int) ну и т.д.
Таблицы разумеется более сложно структуры, но суть отражают. Количество записей - для банков (россии) это сотни тысяч, для телекома - миллионы.

в 3 раза, я думал, что понятно, sorry.
да, конечно, я тоже вот вспомнил последнюю базу по телефонным звонкам -
одни числа. и все же, разница в объемах есть. а когда в дело вступают индексы, то разница становится очень большой.
19 май 06, 04:09    [2682047]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
А что по вашему в основном храниться в БД строки ? Большенство баз в мире имеет отношение к финансовой и производственной деятельности. В них храняться показатели данных сфер деятельности (деньги, количество). Имено с ними и приходиться выполнять такие операции как например суммирование или сложение и вычитание. При больших объемах данных перевод строк в числа и обратно процедура настолько затратная что обещание фантастических скоростей при использовании MUMPS сомнительно.
Что в общем то и подтвердилось у нас. Скорость расчетов на M ситеме оказалась намного меньше чем в том же ORACLE.

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


Чудес не бывает. Не может тот же PHP (который так же использует нетипизированные пременные и является как и MUMPS интерпритатором обогнать в скорости вычислений программу на С).

однозначно не может. а он что, пытался?


Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз.

я просто привык верить собственным глазам и рукам, так что знаю о чем говорю.
19 май 06, 04:20    [2682052]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186

Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз.

я просто привык верить собственным глазам и рукам, так что знаю о чем говорю.[/quot]

Я понимаю когда человек глазам верит (хотя иногда бывает обман зрения), Но чтоб он рукам верил это уже что-то интересное. Ну да ладно это ваши личные проблемы. Вот вам задача конкретная давайте на ней тестировать

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)
Вот вам реальный пример. В начале месяца нагрузка увеличивается раза в 2 так как необходимо выдать немеренное кол- отчетности в том числе и аналитической. И все работает никто особо не жалуется. Одновременно выпоолняются сложные отчеты, заливаются новые данные (в день более 1 млн. записе), расчитывается стоимость разговора и т д. В 2001 году перешли на Оракл потому что система на М просто не справлялась. Жду от вас результатов тестирования на подобном обеме. Тесты на таблице из 100 записей не состоятельны для серьезных систем. Видимо поэтому ни одна из М систем не представлена независимых тестах TCP.
19 май 06, 09:04    [2682266]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

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

в больших математических расчетах
M проигрывает специализированным приложениям. но не
проиграет СУБД, которые под это дело тоже не заточены.

Так во-первых, чаще всего СУБД именно заточены для работы с разными языками (БД в общем случае предназначена для многих приложений и стало быть на разных языках). И потому в паре в такими языками имеют преимущество перед языком М по обоими направлениям. По вычислениям специализрованные приложения, по хранению и обработке СУБД тоже как спекциализированная на БД. Во-вторых, для некоторых специализированных приложений, например, ОЛАП и Датамайнинг СУБД могут иметь дополнительные специализированные возможности (в виде дополнительных опций) - поддерживать Движки для соответсвующих вычислений , напрмер, прогнозирования, распределения и проч.
Я уже пытался сказать об этом. Вы теперь сами почти пришли к этому - кооперация из специализированных часто лучше чего-то одного универсального.
19 май 06, 09:35    [2682375]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные
...
Оракл потому что система на М просто не справлялась. Жду от вас результатов тестирования на подобном обеме. Тесты на таблице из 100 записей не состоятельны для серьезных систем. Видимо поэтому ни одна из М систем не представлена независимых тестах TCP.

хороший тест. а про "железо" можно что-нибудь услышать, чтобы я имел
представление с чем идет сравнение?
19 май 06, 10:22    [2682628]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Joker_Ya

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)


Не надо еще забывать, что в оракле числа хранятся в своем внутреннем, а не в процессорном виде.
19 май 06, 12:16    [2683515]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Sergei Obrastsov

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


И все-таки, я не понимаю, как индексы могут помочь уменьшить объем фактических данных. Если есть такие факты: "Маша", "Даша", "Саша", "Паша", "Глаша" и т.п. как не строй индекс - все равно эти строки останутся. Точно так же и в том же телекоме - если есть продолжительность звонка, то никуда от нее не избавится. Да еще если хранить эту продолжительность в виде строки.
19 май 06, 12:51    [2683743]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Вот и я стал уже кое что понимать каше.
Конечно сжатие данных это круто, но того же самого можно добиться в оракле на индексном кластере. Однако он бычно применяется для нескольких таблиц для ускорения джоинов.

Однако только то что данные занимают меньше места не очень серьезный плюс. Винты сейчас большие и дешевые.

Есть ли еще что нибудь в каше изза чего на него стоит смотреть?

Пока видны такие минусы:
- специалистов по каше мало и они малоподвижы
- распростанена система слабо поэтому найти работу с применением знаний по каше будет сложно, похожих применяемых систем я тоже не знаю, так что нельзя как в рсубд - знаешь sql знаешь как работает версионник а как блокировочник и все на любом движке можно работать
- строгой математической теории, такой как под рсубд без белых пятен и простым решением любой проблемы, под каше нету
(только не надо заваливать ссылками, я же сказал без белых пятен, где ясно абсолютно все)
- по скорости работает также как и все остальное


--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
19 май 06, 12:52    [2683756]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

еще один вопрос: а эти данные нужно получить на всей таблице или только
на выборке за 1 месяц?
19 май 06, 12:54    [2683772]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
AAron
И все-таки, я не понимаю, как индексы могут помочь уменьшить объем фактических данных. Если есть такие факты: "Маша", "Даша", "Саша", "Паша", "Глаша" и т.п. как не строй индекс - все равно эти строки останутся. Точно так же и в том же телекоме - если есть продолжительность звонка, то никуда от нее не избавится. Да еще если хранить эту продолжительность в виде строки.

вот ведь. разве я такое говорил? конечно, меньший объем вряд ли получится,
только за счет сжатия данных, а это чревато нагрузкой при выборке.
но вот объем БД вместе с индексами будет меньше чем у других СУБД на
этих же данных и с такой же индексацией.
19 май 06, 13:00    [2683809]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
Вот и я стал уже кое что понимать каше.
Конечно сжатие данных это круто, но того же самого можно добиться в оракле на индексном кластере. Однако он бычно применяется для нескольких таблиц для ускорения джоинов.

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

pgres

Однако только то что данные занимают меньше места не очень серьезный плюс. Винты сейчас большие и дешевые.

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

pgres

Есть ли еще что нибудь в каше изза чего на него стоит смотреть?
Пока видны такие минусы:
- специалистов по каше мало и они малоподвижы

yeees! правильно, но они уже есть. через год их будет больше.

pgres

- распростанена система слабо поэтому найти работу с применением знаний по каше будет сложно, похожих применяемых систем я тоже не знаю, так что нельзя как в рсубд - знаешь sql знаешь как работает версионник а как блокировочник и все на любом движке можно работать

true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да
работают.

pgres

- по скорости работает также как и все остальное

я бы не стал так говорить, не имея на руках результатов сравнений.
впрочем, я так понимаю, что даже имея такие результаты, вы их
все-равно опротестуете
19 май 06, 13:19    [2683917]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
можно посравнивать для разнообразия, что бы было не голословно
http://msdn2.microsoft.com/en-us/library/ms178085.aspx
http://msdn2.microsoft.com/en-us/library/ms190620.aspx
19 май 06, 13:20    [2683927]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 Sergei Obrastsov
Да что Вы заладили каше - большие объемы данных / данные растут в геометрической прогрессии
до боли напоминает рекламные с программированием ассоциаций
наверное это на тренингах по каше как мантру повторяют

лично у меня с большими объемами данных ассоциируется оракл и дб2

да откройте наконец секрет какие у Вас например объемы и почему так остро стоит проблема дискового пространства

автор

yeees! правильно, но они уже есть. через год их будет больше.


а специалистов по рсубд будет еще больше и прибавляться они будут гораздо быстрее
автор

true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да
работают.

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

рад бы увидеть результаты, а где они я так понимаю надо в табличке 10террабайт смотреть

да к тому же Вам ведь предложили провести сравнение
Joker_Ya

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)

если прочитаете 5 пункт то увидите что данные надо выбирать за месяц

с нетерпением жду результатов

ЗЫ: если результаты будут такими которые легко опротестовать то зачем эти результаты
19 май 06, 14:01    [2684239]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Joker_Ya
[quot ]
т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.


Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных.

>>1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
"простейший инкримент" он и в Африке такой же.. КАШЕ написан на C, как и Оракл, поэтому время увеличения счётчика в оперативной памяти скорее всего будет одинаковым. А если считать записи по мере прохода по всему массиву, так это получится выдуманный пример.. в реальной задаче нужные счётчики скорее всего будут меняться при записи или удалении данных (по крайней мере для проекта на Каше, это естественно)

>>2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
вот тоже самое.. не будет программист на Каше делить на 3600. Там есть встроенные функции преобразования количества секунд во время формата ЧЧ:ММ:СС .. они входят в сам язык, поэтому реализованы на C.

>>3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
вот это сравнение может что нибудь и даст..

4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
с такими объёмами Каше работает.. что подразумевается под умением - не понятно

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