Comments 70
Несколько раз за последние недели ваши посты вижу, но выглядят они для меня как китайская грамота. Вы уж извините, если это ваш продукт, но, имхо, не хватает хотя бы общего описания.
Вот отличная книга для программистов, впервые встречающихся с Caché.
Вы уж извините, если это ваш продукт, но, имхо, не хватает хотя бы общего описания.
Не хватает где: на хабре или вообще?
Если вообще, то материалов предостаточно, например:
Как говорится, читать — не перечитать.
К давнему холивару между сторонниками и противниками запрета сокращённой нотации.
Как видим, если для читателя COS — китайская грамота, то полная нотация или сокращённая — роли не играет.
А если есть что спросить по существу статьи — спрашивайте, отвечу.
Как видим, если для читателя COS — китайская грамота, то полная нотация или сокращённая — роли не играет.
А если есть что спросить по существу статьи — спрашивайте, отвечу.
НУ ведь и правда китайская грамота. Язык ужасен. Платформа была тоже раньше ужасной. Может быть сейчас что-то изменилось.
язык может быть ужасен на первый взгляд, но когда поработаешь с ним, уже так не считаешь.
и к тому же цель статей не показать то какой у нас ужасный язык или ради холивара на тему
а показать существующие возможности интересующимся или сомневающимся в возможностях платформы Cache`
и к тому же цель статей не показать то какой у нас ужасный язык или ради холивара на тему
а показать существующие возможности интересующимся или сомневающимся в возможностях платформы Cache`
Я вот как человек поработавший с ним говорю что язык ужасен. Текущее состояние платформы не знаю, но когда я работал с этой платформой было ужасно.
О феншуйности языков можно дискутировать долго, нудно и без толку.
По самой статье будут вопросы?
По самой статье будут вопросы?
А это когда было?
А что вы делали на этом языке, и как давно?
Выше написал что в 2009. Делали информационную систему для Российского гос. учреждения. Было RIA приложение, где Cache выступал в роли сервера приложений. Тогда отвратительно генерировался WSDL для сервисов. Многие типы получались кривыми. Плюс как сейчас помню прикол. Никогда не выполнялся один условный оператор, в нем вызывалась функция. Стоило вынести вызов функции из условного оператора, и в операторе проверять уже полученное значение, как оператор стал выполняться.
Про глобалы я вообще молчу. Это единственное за что на Cache можно посмотреть, но и то, чего я никогда не посоветовал бы использовать. Это абсолютно бессмысленный вынос мозга. Сложно, без полноценной поддержки целостности типов, зачем то придуманный черный ход. Это своего рода костыль, для решения проблем с производительностью реляционного и объектного представления.
Про глобалы я вообще молчу. Это единственное за что на Cache можно посмотреть, но и то, чего я никогда не посоветовал бы использовать. Это абсолютно бессмысленный вынос мозга. Сложно, без полноценной поддержки целостности типов, зачем то придуманный черный ход. Это своего рода костыль, для решения проблем с производительностью реляционного и объектного представления.
Плюс как сейчас помню прикол. Никогда не выполнялся один условный оператор, в нем вызывалась функция. Стоило вынести вызов функции из условного оператора, и в операторе проверять уже полученное значение, как оператор стал выполняться.Да, функция возвращала именно нужное условному оператору значение. При чем проблема была именно в одной функции, мы не поняли в чем проблема, и просто положили значение в переменную, а потом сверяли с переменной.
Это не костыль — и реляционное и объектное представление — это просто один из интерфейсов к глобалам, то есть из каше можно выкинуть и объекты и sql — но глобалы нельзя — это основа.
А насчёт вызова функций — то можно было проанализировать ошибку и стек, и разобраться что там не так.
А насчёт вызова функций — то можно было проанализировать ошибку и стек, и разобраться что там не так.
А насчёт вызова функций — то можно было проанализировать ошибку и стек, и разобраться что там не так.Анализировали, смотрели и не поняли… :(
Это не костыль — и реляционное и объектное представление — это просто один из интерфейсов к глобалам, то есть из каше можно выкинуть и объекты и sql — но глобалы нельзя — это основа.А я имею ввиду что это костыль, по сравнению с другими системами. Конечно это основа. Только такую основу надо скрывать и не давать ей пользоваться. Все технологии стремятся к более высокоуровневым средствам. И что-бы эти средства работали как можно быстрее. Но почему решили открыть черный ход, дать доступ к внутренностям, но зато мы будем самая быстрая СУБД в мире.
потому что это не чёрный путь а очень эффективный способ работы с данными, если вам не нравятся глобалы не работайте с ними, но пока-что? кроме эмоций, ни одного замечания по существу, насчёт глобалов, я не услышал. С WSDL в Cache — не работал — спорить не буду.
Заметьте, я не отрицал что это работает быстро. И, судя по всему, Ваше слово эффективно именно это и отражает. Я говорю, что это самый неудобный способ. Быстро это да, но это как зубы у проктолога лечить.
Замечание про то, что не поддерживается полноценно целостность, разве не есть по существу?
Все пытаются сделать так, что бы разрабатывать и поддерживать было легко, особенно для энтерпрайз разработки, но в случае с Cache все наоборот. Для эффективной работы надо опускаться до глобалов. Жесть. :) Плюс ко всему уродский и избыточный синтаксис.
Но да, на глобалах очень быстро.
В общем спорить больше не будем, все таки блог InterSystems.
Замечание про то, что не поддерживается полноценно целостность, разве не есть по существу?
Все пытаются сделать так, что бы разрабатывать и поддерживать было легко, особенно для энтерпрайз разработки, но в случае с Cache все наоборот. Для эффективной работы надо опускаться до глобалов. Жесть. :) Плюс ко всему уродский и избыточный синтаксис.
Но да, на глобалах очень быстро.
В общем спорить больше не будем, все таки блог InterSystems.
Спорить не будем — но лечить зубы у проктолога — это некорректная метафора — здесь зубы как раз лечатся у стоматолога, насчёт целостности, опять же не согласен, сам слежу за ней, и просматриваю файл INTEGRIT.LOG — раз в неделю, для убеждения в том что всё ок. И самое главное, что я хочу до вас донести — что глобалы это действительно легко, может быть немного необычно, но очень и очень легко, это легче даже чем sql и объекты, честно, небольшое усилие — чтобы разобраться и всё. Но опять же не будем спорить я вас не пытаюсь переубедить.
И самое главное, что я хочу до вас донести — что глобалы это действительно легко, может быть немного необычно, но очень и очень легко, это легче даже чем sql и объекты, честно, небольшое усилие — чтобы разобраться и всё. Но опять же не будем спорить я вас не пытаюсь переубедить.
По моему мнению легко, это работать с запросами и данными, используя приятный язык с хорошим IntelliSense, без возможности испортить целостность данных. Все остальное есть усложнение решения задачи. Ведь есть с чем сравнить…
Я бы не сказал, что у MUMPS синтаксис более уродский и избыточный, чем у SQL. А главное, что, на глобалах и объектах, как говорил персонаж «Золотого телёнка», «как пожелаем, так и сделаем».
Кстати насчет длины битовой строки, у вас в тексте написано об ограничении битовой строки в 256K
и при этом в исходнике есть
но не описана причина использования такой длины, а это важно было на ранних версиях, не думаю что в последних версиях сильно что изменилось
и при этом в исходнике есть
/// Maximal length of $bit string to use
Parameter MAXBITLENGTH = 64000;
но не описана причина использования такой длины, а это важно было на ранних версиях, не думаю что в последних версиях сильно что изменилось
Не нужно путать максимальную длину битовой строки вообще и длину чанка bitmap-индексов для таблиц в частности.
Ещё можете посмотреть в исходниках значение $$$DeepSeeBitsPerChunk, BitsPerChunk, $$$BitMapSize.
The maximum bitstring length is 262,104 bits (32763 x 8).
источник
The third subscript contains a chunk number; for efficiency, bitmap indices are divided into a series of bitstrings each containing information for about 64000 rows from the table. Each of these bitstrings are referred to as a chunk.
источник
Ещё можете посмотреть в исходниках значение $$$DeepSeeBitsPerChunk, BitsPerChunk, $$$BitMapSize.
ОК, тогда в чем разница между chunk'ом и битовой строкой?
Чанки — всего лишь частный случай битовых строк.
Чанки используются в таблицах для хранения bitmap/bitslice индексов и за их формированием и использованием следит сама система.
А битовые строки — это общий случай и Вы можете у себя в коде их использовать как угодно.
PS: есть мысль, что 64000 бита на чанк тянутся со времён, когда не было длинных строк. А для перехода на новую (большую) длину чанка требовалось бы перегенерировать индексы и подкорректировать пользовательский код, работающий с чанками напрямую, если там есть жёсткая привязка к такой длине. Возможно, когда-то в будущих версиях это и случится.
Чанки используются в таблицах для хранения bitmap/bitslice индексов и за их формированием и использованием следит сама система.
А битовые строки — это общий случай и Вы можете у себя в коде их использовать как угодно.
PS: есть мысль, что 64000 бита на чанк тянутся со времён, когда не было длинных строк. А для перехода на новую (большую) длину чанка требовалось бы перегенерировать индексы и подкорректировать пользовательский код, работающий с чанками напрямую, если там есть жёсткая привязка к такой длине. Возможно, когда-то в будущих версиях это и случится.
разница между чанком и битовой строкой никакой, кроме того, что чанк это битовая строка часть массива битовых строк
а вот на счет 64000 ссылка
а вот на счет 64000 ссылка
А эта проблема уже исправлена в версии 2013.2.
вот-вот, исправлена в версии которая еще не доступна даже в FT.
так что размер битовой строки все же лучше пока ограничивать в 64000 бит
и есть еще один нюанс, данные в БД со стандартным размером блоков в 8Kb, с битовыми строками в 64000 бит и более, не будут кешироваться при работе в конфигурации ECP.
хотя это может быть тоже уже поправлено в будущей версии.
так что размер битовой строки все же лучше пока ограничивать в 64000 бит
и есть еще один нюанс, данные в БД со стандартным размером блоков в 8Kb, с битовыми строками в 64000 бит и более, не будут кешироваться при работе в конфигурации ECP.
хотя это может быть тоже уже поправлено в будущей версии.
Заключительный ответ в указанной теме — мой.
А можно реальный пример, потому что чёрные и жёлтые крокодилы — несколько сбивают.
Поясню вопрос, для чего я хочу реальный пример — так это для того что бы понять какие именно задачи эффективно решаются битмап-индексами (не в SQL) — в вашей системе, само решение более или менее красиво и понятно, но вот область его разумного эффективного применения, пока -что не совсем улавливаю. Как например, на все эти операции добавить релевантность, которая явно содержит плавающую точку. Каким образом устроена нумерация идентификаторов, какие будут потери, если идентификаторы не идут подряд?
Напишу реальный пример, то как используем Bitmap индексы в нашей системе.
Bitmap индексы у нас основные и мы практически не используем стандартные SQL-индексы и вообще SQL
наше приложение это СЭД, большая часть данных представляет собой как и в большинстве систем это документ с набором полей
мы индексируем связь значение свойства название свойства и собственно сам документ, примерно так:
^Index(«FieldName»,«FieldValue»,1)=$bit(0,1,0,1)
соответственно мы можем поискать список документов со значением FieldValue в поле FieldName, и мы получим битовый массив со всеми таким документами. и мы так же мы можем быстро с помощью битовых операций добавить условия поиска документов, в нашей системе это очень удобно и достаточно быстро. Самый большой минус правда, когда количество чанков в битовом массиве становится очень большим.
Bitmap индексы у нас основные и мы практически не используем стандартные SQL-индексы и вообще SQL
наше приложение это СЭД, большая часть данных представляет собой как и в большинстве систем это документ с набором полей
мы индексируем связь значение свойства название свойства и собственно сам документ, примерно так:
^Index(«FieldName»,«FieldValue»,1)=$bit(0,1,0,1)
соответственно мы можем поискать список документов со значением FieldValue в поле FieldName, и мы получим битовый массив со всеми таким документами. и мы так же мы можем быстро с помощью битовых операций добавить условия поиска документов, в нашей системе это очень удобно и достаточно быстро. Самый большой минус правда, когда количество чанков в битовом массиве становится очень большим.
что значит очень большим?
когда чанков стало сотни, т.е. количество объектов в битовом массиве стало миллионы, скорость работы системы стала падать при обработке таких битовых массивов.
ещё вопрос, а какие будут потери если нумерация объектов идёт не подряд?
Желательно чтобы сами объекты конечно шли по порядку, но в битовом массиве это уже большого значения не имеет.
то есть если объекты идут не по порядку то — это приведёт к большему использованию чанков на меньшем количестве объектов я верно понимаю?
по сути да, рекомендуемый размер чанка 64000 бит
соответственно наибольшая производительности достигается когда общее количество документов не превышает 64000
у нас большая часть классов документов имеют общий предок и общую нумерацию ID.
и так же мы используем так называемое хранилище для разрезов массива чтобы объединить объекты одного логического функционала в общий битовый массив что позволит с применением разных алгоритмов оптимизации достичь улучшений производительности
так же еще минусом конечно идет разреженность битового массива если в выборку попадет 100 документов и каждый из попадет в отдельный чанк массива, то это конечно очень плохо
соответственно наибольшая производительности достигается когда общее количество документов не превышает 64000
у нас большая часть классов документов имеют общий предок и общую нумерацию ID.
и так же мы используем так называемое хранилище для разрезов массива чтобы объединить объекты одного логического функционала в общий битовый массив что позволит с применением разных алгоритмов оптимизации достичь улучшений производительности
так же еще минусом конечно идет разреженность битового массива если в выборку попадет 100 документов и каждый из попадет в отдельный чанк массива, то это конечно очень плохо
И самое главное — после получения набора объектов — можно ли, например быстро, извлечь первые несколько из них, но по принципу релевантности, которая меняется независимо от признаков по которым мы ищем? И как это сделать?
да с релевантностью уже сложнее, можно только обойти список документов отсортированному по ID документа.
и чтобы его как то отсортировать нужен сортирующий индекс.
и чтобы его как то отсортировать нужен сортирующий индекс.
а битслайсы используете вы или нет?
да и их тоже но поменьше, их применение это ускорение математических операций
быстро считать количество/суммы
используем для отчетов, когда нужно посчитать сумму значений в нужном поле для выборки документов
быстро считать количество/суммы
используем для отчетов, когда нужно посчитать сумму значений в нужном поле для выборки документов
а по скольким приблизительно полям строите индекс (объектов я так понял у вас миллионы), и ещё вопрос — объекты часто добавляются/удаляются/изменяются каков порядок правок в сутки? Как на вводе это всё работает не тормозит?
тут конечно все зависит от проекта
на том что сейчас у нас наиболее активный, то там мы имеем более терабайта индексов, индексы занимают больше места чем сами данные.
насчет объема правок, то например журналов в сутки больше может быть в районе 20-40 GB
ну насчет тормозит, тут работаем над быстродействием, совершенства еще не достигли
на том что сейчас у нас наиболее активный, то там мы имеем более терабайта индексов, индексы занимают больше места чем сами данные.
насчет объема правок, то например журналов в сутки больше может быть в районе 20-40 GB
ну насчет тормозит, тут работаем над быстродействием, совершенства еще не достигли
20,40 GB — на терабайты индексов в день для журналов, как мне кажется не так уж и много (хотя конечно не могу считать себя здесь супер-профессионалом)
Или же надо выполнять дополнительную операцию обработки уже получившегося массива данных?
Для данных с плавающей точкой нам в своё время не удалось добиться существенного выигрыша. Воспользовались тем, что в наших приложениях данные могут быть представлены в формате с фиксированной точкой.
Эмпирически было получено, что использование битмап-индексов для выборки данных оправдано всегда, во всяком случае, на базах до 50 гигабайт. С использованием битслайсов для вычисления группирующей функции ситуация немного другая. Выигрыш у нас получался, если в каждой группировке участвовало в среднем более 5 записей.
Эмпирически было получено, что использование битмап-индексов для выборки данных оправдано всегда, во всяком случае, на базах до 50 гигабайт. С использованием битслайсов для вычисления группирующей функции ситуация немного другая. Выигрыш у нас получался, если в каждой группировке участвовало в среднем более 5 записей.
А в Cache 2009 можно использовать MAXBITLENGTH 262104 вместо 64000 или есть какие-то ещё причины такого ограничения? просто смотрю сюда docs.intersystems.com/ens20091/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fbit#RCOS_B40662 и не понимаю откуда взялось 64000
вот посмотрите
это я уже видел, то есть в версии 2009 и версии 2012 — проблема всё ещё есть верно?
насколько я понимаю да
А AdHoc'и разве уже отменили?
простите что такое AdHoc'и?
Патчи. Разве ни разу не заказывали?
Необязательно ждать новой версии, чтобы исправить ошибку в уже существующей.
Необязательно ждать новой версии, чтобы исправить ошибку в уже существующей.
дело в том, что я не использовал битмапиндексы ранее (основной юзкейс не предусматривает множественной выборки на одном шаге) — и этот патч мне был не нужен, (хотя теперь я вижу те места, в своей системе, в которых можно получить некоторый выигрыш от их использования)
Для стандартных bitmap-индексов патч не нужен, так как там длина ограничена в 64000 бита.
А если свои bitmap-индексы будете использовать с длиной >64000 бит, то да — может пригодиться
А если свои bitmap-индексы будете использовать с длиной >64000 бит, то да — может пригодиться
что значит стандартный bitmap-индекс?
Bitmap Indices
Тот, за который отвечает сама Caché и который используется движком SQL и DeepSee (для MDX-запросов) для ускорения запросов.
Тот, за который отвечает сама Caché и который используется движком SQL и DeepSee (для MDX-запросов) для ускорения запросов.
Sign up to leave a comment.
Bitmap-индексы в Caché на глобалах