Здравствуйте, Merle, Вы писали:


M>>>В среднем это десятки — сотни гигабайт, миллионы и десятки миллионов записей на таблицу.
S>> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек. А учитывая Кэши Raid массивов и их пропускной способности уложится в часы нужно сильно постараться.
M>Ты хорошо себе представляешь, что такое OLAP и каким образом там кубы считаются? Это не массив int'ов, проиндексированый. Там очень большая избыточность, куб формируется из относительно небольшой OLTP системы, таким образом, чтобы последующие запросы к нему не требовали практически никаких объединений. И этот процесс занимает несколько часов. Зато когда на утро приходят клиенты и манагеры, запросы на чтение по такой системе летают не за 10 сек, а гораздо меньше.
Да прекрасно я себе ее представляю. А пример привел для соотношеня скоростей. Просто в SQL и страница под страницу индекса составляет 8 кб а это тормоза на вставку, да и в качестве таблицы лучше применять Хэш таблицу а не кластерный индекс. Руками все это очень легко реализуется. Вообще в SQL именно на вставку модификацию работает сравнительно плохо.
Кстати для смеха проводили тест 100 тыс записей по 400 байт как аналог кластерного индекса за 1.6 секунды, на дженериках типа Б+ деревьях типа Key,Value
S>> А запрос куда переводится???? Теже Б деревья, Хэш таблицы итд наверное компилируются, иначе скорость выполнения запроса была бы как на Аксессе.
M>Компиляция запроса занимает вообще смешное время, дороже всего обходится расчет оптимального плана выполнения, поэтому планы кешируются.
Ну ясен пень не каждый же раз компилировать. А теперь представь ситуацию когда ты сам пишешь весь план запроса ручками и компилируется быстро или берется уже скомпилированный алгоритм. А вот в Аксессе такого нет. Особенно для сложных алгоритмов.
S>> В данном случае можно говорить о неком компилируемом языке, использующий оптимизатор запросов и статистику.
M>Так в том-то и фокус, что для объектов напрямую, минуя реляционную стадию, неьзя такого придумать. Точнее может и можно, но пока никто не додумался.
Так в том то и суть, что этого и не нужно (Вернее на данном этапе) и полностью использовать все наработки РБД но на новый лад. Но о чем можно говорить если даже в Юконе в ХП нельзя использовать объекты. А насчет додуматься то уверяю что наработок скорей всего очень много, а вот изменить ооочень сложную систему то на это потребуется огромное количество времени и сил. Все пока идет эволюционным путем, но все же идет.

Здравствуйте, Serginio1, Вы писали:

S> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек.

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

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Так для примера в тестах с общим результирующем количестве группировок 10 миллионов на Int на Хэш таблицах с 0 капасити менее 10 сек.

M>Вот, кстати, вспомнился простенький тестик... Допустим есть 1000000 интов, монотонно возрастающих. В них 1000 разрывов. за сколько твоя система выдаст начало и конец каждого непрерывного участка?
Ну обычным пробегом за сотые доли секунды. Кстати разбор текста на строки 150 MB 10 милионов строк без выделения менее 2 сек, с выделение 3 сек.

Здравствуйте, Serginio1, Вы писали:

S> Да прекрасно я себе ее представляю. А пример привел для соотношеня скоростей. Просто в SQL и страница под страницу индекса составляет 8 кб а это тормоза на вставку,
С какой стати? Ты предлагаешь размер страницы равный размеру записи делать?

S> да и в качестве таблицы лучше применять Хэш таблицу а не кластерный индекс.
Ага лучше, если эта таблица в память влезает. А если не влезает, то труба. А в БД она по определению не влезает.

S> Руками все это очень легко реализуется. Вообще в SQL именно на вставку модификацию работает сравнительно плохо.
По сравнению с чтением — конечно.

S> А теперь представь ситуацию когда ты сам пишешь весь план запроса ручками и компилируется быстро или берется уже скомпилированный алгоритм.
А ты представь ситуацию, когда у тебя оптимальный план меняется от запроса к запросу, а тот что был оптимальным в прошлый раз — сейчас один из самых тормозных.
Вот в таких ситуациях БД и выручает грамотно собранная статистика в компании с хорошим оптимизатором. Само руками такое в принципе не делается.

S> Но о чем можно говорить если даже в Юконе в ХП нельзя использовать объекты.
Почему нельзя? берешь любой Net язык и вперед...

Здравствуйте, Serginio1, Вы писали:

S> Ну обычным пробегом за сотые доли секунды. Кстати разбор текста на строки 150 MB 10 милионов строк без выделения менее 2 сек, с выделение 3 сек.
Это ты проверил или на вскидку сказал? Или ты под каждую задачу оптимальный алгоритм реализуешь?

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Да прекрасно я себе ее представляю. А пример привел для соотношеня скоростей. Просто в SQL и страница под страницу индекса составляет 8 кб а это тормоза на вставку,
M>С какой стати? Ты предлагаешь размер страницы равный размеру записи делать?
Нет конечно тем более записи. Размер страницы индекса должен подбираться для оптимальной скорости вставки. Но это впрочем не важно, т.к. основная скорость на чтение а там как раз высота дерева более критична.

S>> да и в качестве таблицы лучше применять Хэш таблицу а не кластерный индекс.
M>Ага лучше, если эта таблица в память влезает. А если не влезает, то труба. А в БД она по определению не влезает.

Ну зачем сразу в память. На диск, все равно файл кэшируется на уровне системы, хотя и ручками можно постранично держать в памяти.
S>> Руками все это очень легко реализуется. Вообще в SQL именно на вставку модификацию работает сравнительно плохо.
M>По сравнению с чтением — конечно.

S>> А теперь представь ситуацию когда ты сам пишешь весь план запроса ручками и компилируется быстро или берется уже скомпилированный алгоритм.
M>А ты представь ситуацию, когда у тебя оптимальный план меняется от запроса к запросу, а тот что был оптимальным в прошлый раз — сейчас один из самых тормозных.
На самом деле таких ситуаций очень мало, и сколько нужно статистики например для 100 000 товаров, где то прямое чтение всех записей а где то и другой подход. Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам.
M>Вот в таких ситуациях БД и выручает грамотно собранная статистика в компании с хорошим оптимизатором. Само руками такое в принципе не делается.

S>> Но о чем можно говорить если даже в Юконе в ХП нельзя использовать объекты.
M>Почему нельзя? берешь любой Net язык и вперед...
Использую Хэш таблицы итд ????

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Ну обычным пробегом за сотые доли секунды. Кстати разбор текста на строки 150 MB 10 милионов строк без выделения менее 2 сек, с выделение 3 сек.
M>Это ты проверил или на вскидку сказал? Или ты под каждую задачу оптимальный алгоритм реализуешь?
Проверил Вот сдесь результаты тестов
http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019
Также исходники объектов для последовательного чтения текстовых файлов
как в прямом так и в обратном направлении TTextReader и TTextBackReader использующие кольцевой буффер размером 64 кб с ограничением на длину строки 64 кб — 3 байта.
Сразу предупреждаю, что не протестированы на все граничные условия.

А то народ через стринглист все читает, особенно много вопросов а как прочитать 9000 запись с начала или с конца. Вот и сделал простенькие объекты для чтения и записи и сравнил со стандартными. Правда эти результаты на откэшированных файлах.

может кто все же догадается посмотреть на промышленые реализации ?


1. на как и чем крутится Lotus Notes — это не RDBMS, но есть вариант что под низом у нее все таки DB2.
2. как и где работает промышленая ООСУБД Cashe

п1 ответит на 2/3 вопросов ...

Gt_

Здравствуйте, Serginio1, Вы писали:

S> Размер страницы индекса должен подбираться для оптимальной скорости вставки.
Ну тоже достаточно спорно, от задачи зависит...

S> Ну зачем сразу в память. На диск, все равно файл кэшируется на уровне системы, хотя и ручками можно постранично держать в памяти.
И вот тут-то все достоинства хеш-таблиц дружно присядут. Поскольку по диску придется елозить гораздо больше, чем при B+дереве и в менее предсказуемом режиме, а дисковые операции самые дорогие.
А если еще и про многопользовательскую работу вспомнить — то вообще труба.

S> На самом деле таких ситуаций очень мало, и сколько нужно статистики например для 100 000 товаров, где то прямое чтение всех записей а где то и другой подход.
И ситуаций гораздо больше чем кажется, и усредненные алгоритмы серьезно проигрывают оптимальным. Все-таки БД сейчас не зря такие, какие они есть.

S>Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам.
Ну вот это ты не прав. Выигрыш от правильного использования статистики существенно больше чем издержки на ее своевременное поддержание.

S> Использую Хэш таблицы итд ????
А что, ты хотел движек БД напрямую из хранимок пользовать?

Здравствуйте, Аноним, Вы писали:

А>может кто все же догадается посмотреть на промышленые реализации ?
Дык, где они?

А>1. на как и чем крутится Lotus Notes — это не RDBMS, но есть вариант что под низом у нее все таки DB2.
Ну ты посоветовал...
Во первых на это чудо лучше вообще не смотреть.
А во вторых у Лотуса там в нутрях не DB2. Я тебе больше скажу, ИБМ-цам занадоело смотреть куда лотус катится и они это дело как раз под ДБ2 переписывать собираются, чтобы к этим вечным тормозам нормальный тепловоз приделать.

А>2. как и где работает промышленая ООСУБД Cashe
Ага ОО.. Где там эти две буквы? Даже сами хлопцы из интерсустемса аккуратненько называют ее "постреляционная", так как не смотря на все потуги она ни какая не объектная, а очень хорошо написанная иерархическая БД. Ну максимум сетевая.

А>п1 ответит на 2/3 вопросов ...
Как много нам открытий чудных...

Здравствуйте, Serginio1, Вы писали:

По-моему разговор съезжает с темы. Давай вернемся немного назад. Вот сюда:

Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)

Это гипотетический язык. Семантика ясна? На всякий случай я поясню: мы хотим найти множество всех объектов, которые реализуют интерфейсы IAmountable и ISecuredObject. При этом значение, возвращаемое методом IAmountable.Amount() должно превышать 100, а метод ISecuredObject.AllowsAccess() должен возвращать "истина" при передаче ему в качестве параметра менеджера текущего пользователя.
В базе живет, скажем, N ~ 1e7 объектов. Интерфейс ISecuredObject реализован примерно в 300 из 1000 зарегистрированных классов; интерфейс IAmountable — в 20. Одновременно с системой работают на R/W 50 пользователей, на R 500.
Ты не мог бы ответить на несколько простых вопросов (не вдаваясь в технические детали):
1. Каким образом будет выглядеть план этого запроса?
2. Какова ожидаемая зависимость быстродействия этого запроса от N?
3. Каким образом можно построить этот план, имея на входе декларативное описание запроса, вроде вышеописанного? Учитывая то, что вообще говоря есть инкапсуляция, т.е. все состояние объекта помечено как private.

Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Размер страницы индекса должен подбираться для оптимальной скорости вставки.
M>Ну тоже достаточно спорно, от задачи зависит...

S>> Ну зачем сразу в память. На диск, все равно файл кэшируется на уровне системы, хотя и ручками можно постранично держать в памяти.
M>И вот тут-то все достоинства хеш-таблиц дружно присядут. Поскольку по диску придется елозить гораздо больше, чем при B+дереве и в менее предсказуемом режиме, а дисковые операции самые дорогие.
M>А если еще и про многопользовательскую работу вспомнить — то вообще труба.

Ну ну. Какое елозание если страницы кэшированы в памяти. А на Б+ дереве как бы там не было а в зависимости от количества уровней обратится придется еще больше, т.к. в среднем за 1.3 попытки находится результат в Хэш таблице. плюс Log(N) сравнений.

S>> На самом деле таких ситуаций очень мало, и сколько нужно статистики например для 100 000 товаров, где то прямое чтение всех записей а где то и другой подход.
M>И ситуаций гораздо больше чем кажется, и усредненные алгоритмы серьезно проигрывают оптимальным. Все-таки БД сейчас не зря такие, какие они есть.

Все зависит от ситуации. Тоесть собирается вся статистика по всем 100 000 для различный запросов ????? Да там статистика больше базы будет которая кто му же сильно меняется.

S>>Но если брать некий усредненный алгоритм, то в среднем он и будет оптимальным, нежели ослеживать статистику по всем товарам.
M>Ну вот это ты не прав. Выигрыш от правильного использования статистики существенно больше чем издержки на ее своевременное поддержание.
Очень спорно, все зависит от ситуации. Значит ты не веришь в теориЮ Вероятностей???
S>> Использую Хэш таблицы итд ????
M>А что, ты хотел движек БД напрямую из хранимок пользовать?
Нет конечно, но промежуточные результаты вполне возможно вычислять. Или это прерогатива только клиента ????

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>По-моему разговор съезжает с темы. Давай вернемся немного назад. Вот сюда:
S>

S>Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)
S>

S>Это гипотетический язык. Семантика ясна? На всякий случай я поясню: мы хотим найти множество всех объектов, которые реализуют интерфейсы IAmountable и ISecuredObject. При этом значение, возвращаемое методом IAmountable.Amount() должно превышать 100, а метод ISecuredObject.AllowsAccess() должен возвращать "истина" при передаче ему в качестве параметра менеджера текущего пользователя.
S>В базе живет, скажем, N ~ 1e7 объектов. Интерфейс ISecuredObject реализован примерно в 300 из 1000 зарегистрированных классов; интерфейс IAmountable — в 20. Одновременно с системой работают на R/W 50 пользователей, на R 500.
S>Ты не мог бы ответить на несколько простых вопросов (не вдаваясь в технические детали):
S>1. Каким образом будет выглядеть план этого запроса?
S>2. Какова ожидаемая зависимость быстродействия этого запроса от N?
S>3. Каким образом можно построить этот план, имея на входе декларативное описание запроса, вроде вышеописанного? Учитывая то, что вообще говоря есть инкапсуляция, т.е. все состояние объекта помечено как private.
А пробежаться по метаданным, и запросить у типа поддерживает ли он некий интерфейс и являются ли эти юзеры манагерами. Банальный перебор. А 1e7 типов очень проблематично вообще сделать. В данном случае опять опираясь на реляционные или еще какие БД то данные объектов хранятся в одном своем хранилище и нужно проверить соответствие только у типа и если оно правильно просто запросить количество экземпляров этого типа.
S>Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым.
Может я, что то не правильно объяснил????

Здравствуйте, Serginio1, Вы писали:
S> А пробежаться по метаданным, и запросить у типа поддерживает ли он некий интерфейс и являются ли эти юзеры манагерами. Банальный перебор.
Хм. Ну пробежались мы. Хорошо, оба интерфейса поддерживаются 20 классами. У нас есть список этих классов, полученный (пока что) линейным перебором. На таких количествах большого смысла делать супероптимизации нет. Поехали дальше.
S>А 1e7 типов очень проблематично вообще сделать.
Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета.
S>В данном случае опять опираясь на реляционные или еще какие БД то данные объектов хранятся в одном своем хранилище и нужно проверить соответствие только у типа и если оно правильно просто запросить количество экземпляров этого типа.
Видишь ли, нам надо не количество экземпляров типа. Пусть их оказалось, скажем, 50000 (всех 20 классов меньше взятых) Надо узнать, какие из этих экземпляров удовлетворяют предикату. Про это у тебя ни слова нет.
S>>Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым.
S> Может я, что то не правильно объяснил????
Да ты пока еще ничего не объяснил. Продолжай. Расскажи мне, каким алгоритмом мы будем выполнять запрос.

А>>2. как и где работает промышленая ООСУБД Cashe
А>Ага ОО.. Где там эти две буквы? Даже сами хлопцы из интерсустемса аккуратненько называют ее "постреляционная", так как не смотря на все потуги она ни какая не объектная, а очень хорошо написанная иерархическая БД. Ну максимум сетевая.

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

4. Adoption of a Post-Relational Database

Post-relational (a.k.a., transactional multidimensional) databases such as Caché implement an associative array technology that can be projected to an object or relational model simultaneously and without intervening mapping tools or caching middle tiers.

http://www.intersystems.com/cache/technology/whitepapers/impedance.html


P.s. про лотус попозже ...

Gt_

Здравствуйте, Аноним, Вы писали:

А>вы наверно на сайт даже зашли
Ххха! зашел..

А>но все же надо было бы чуть ниже посмотреть ...
Нееее, ниже не надо.
На кой фиг мне на их сайт смотреть, если я на ней работал?

А>Post-relational (a.k.a., transactional multidimensional) databases such as Caché implement an associative array technology that can be projected to an object or relational model simultaneously and without intervening mapping tools or caching middle tiers.
Как тут кто-то очень верно заметил, словом "объект" кидаются все кому не лень, но никто не понимает, что это такое. Все тока чувствуют, но словами никто сказать не может. Так что я тут могу вполне авторитетно заявить — объектного в ней только несколько строчек в рекламных статьях.

А>P.s. про лотус попозже ...
Any time.
У меня как раз лотусятник тока-тока с ИБМ-овского семинара вернулся.

А>>1. на как и чем крутится Lotus Notes — это не RDBMS, но есть вариант что под низом у нее все таки DB2.
А>Ну ты посоветовал...
А>Во первых на это чудо лучше вообще не смотреть.
А>А во вторых у Лотуса там в нутрях не DB2. Я тебе больше скажу, ИБМ-цам занадоело смотреть куда лотус катится и они это дело как раз под ДБ2 переписывать собираются, чтобы к этим вечным тормозам нормальный тепловоз приделать.

не видели рекламу когда не нужно больше говорить ?

Relational database management system
The remainder of the data used by the LMS is stored in a third-party relational database management system (RDBMS). Although the RDBMS is a third-party product, it is a fundamental component of the Lotus Learning Management System. Data regarding user privileges, courses, and resources is stored in the database management system and accessed as needed.

как я и предполагал под низом одна из 3х бд db2, oracle или mssql

http://www-10.lotus.com/ldd/today.nsf/a2535b4ba6b4d13f85256c59006bd67d/e397f5d73ff17c4f85256cd40064f3ef?OpenDocument


Gt_

Здравствуйте, Vasiliy_Krasnokutsky, Вы писали:

V_K>Добрый день,
V_K>прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql.
V_K>Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных.
V_K>Желательно бы ссылки на статьи или книги.

V_K>Заранее благодарен, Краснокутский Василий


Что там Oracle & SQLServer, я вот слышал что на новом круизном лайнере (тот который побольше Титаника) Progress RDBMS поставили — вот это круто
Так что Oracle & SQLServer — вчерашний день
Теперь можно смело ждать очередного айсберга и пышных похорон

Здравствуйте, Sinclair, Вы писали:

S>Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета.

Вот к примеру кондитерская фабрика. В среднем ок. 100 позиций в накладной, ок. 200 накладных в сутки (оптовые продажи). При минимальной 3-хскладовой системе имеем 5 накладных (прих., расх., 2 перемещения). Итого 100 тыс. записей в сутки. Хранить в оперативной БД нужно данные минимум за пару лет.
100тыс. * 365 * 2 это почти 1е8. И это довольно скромная оценка. Предлагаю взять 1е9 записей как верхнюю оценку.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>> А пробежаться по метаданным, и запросить у типа поддерживает ли он некий интерфейс и являются ли эти юзеры манагерами. Банальный перебор.
S>Хм. Ну пробежались мы. Хорошо, оба интерфейса поддерживаются 20 классами. У нас есть список этих классов, полученный (пока что) линейным перебором. На таких количествах большого смысла делать супероптимизации нет. Поехали дальше.
S>>А 1e7 типов очень проблематично вообще сделать.
S>Я же сказал — типов около 1000. А 1e7 экземпляров — фигня для OLTP системы. Прикинь, сколько объектов класса ПозицияНакладной может жить в типичной системе складского учета.
S>>В данном случае опять опираясь на реляционные или еще какие БД то данные объектов хранятся в одном своем хранилище и нужно проверить соответствие только у типа и если оно правильно просто запросить количество экземпляров этого типа.
S>Видишь ли, нам надо не количество экземпляров типа. Пусть их оказалось, скажем, 50000 (всех 20 классов меньше взятых) Надо узнать, какие из этих экземпляров удовлетворяют предикату. Про это у тебя ни слова нет.
Select from * where IAmountable.Amount() > 100.0 and ISecuredObject.AllowsAccess((Context.User as Employee).Manager)

Ну простым перебором по 50000 это вообще милисекунды. А если ISecuredObject.AllowsAccess((Context.User as Employee).Manager)==false то вообще бегать.

S>>>Как только мы ответим на три этих простых вопроса, все станет мягким и шелковистым.
S>> Может я, что то не правильно объяснил????
S>Да ты пока еще ничего не объяснил. Продолжай. Расскажи мне, каким алгоритмом мы будем выполнять запрос.
Учитывая, что за выборку отвечает некий объект, считывая данные в поле объекта. Все очень просто.