В СУБД Caché для ускорения таких запросов предусмотрен специальный тип индекса: BITSLICE
Сделал небольшой тест (для ускорения заполнения таблицы использовал не SQL, а прямой доступ). Время везде приводится в секундах.
Код класса (он же таблица)
Class demo.test Extends (%Persistent, %IndexBuilder)
{
Index idxClicks On clicks [ Type = bitslice ];
Property d As %Date;
Property browserid As %Integer [ Required, SqlFieldName = browser_id ];
Property bannerid As %Integer [ Required, SqlFieldName = banner_id ];
Property views As %Integer;
Property clicks As %Integer;
ClassMethod Fill()
{
set time=$zhorolog
set succ(0)=0
set succ(1)=0
set succ(2)=50
set succ(3)=500
set insucc(0)=0
set insucc(1)=0
set insucc(2)=400
set insucc(3)=400000
do DISABLE^%NOJRN
do ..%KillExtent()
set i=0
for d=$horolog-99:1:$horolog {
for browserid=0:1:99 {
for bannerid=0:1:999 {
set succ=succ($random(4))
set insucc=insucc($random(4))
set i=i+1
set ^demo.testD(i)=$listbuild("",d,browserid,bannerid,succ+insucc,succ)
}
}
}
set ^demo.testD=i
do ENABLE^%NOJRN
Для стандартных bitmap-индексов патч не нужен, так как там длина ограничена в 64000 бита.
А если свои bitmap-индексы будете использовать с длиной >64000 бит, то да — может пригодиться
Чанки — всего лишь частный случай битовых строк.
Чанки используются в таблицах для хранения bitmap/bitslice индексов и за их формированием и использованием следит сама система.
А битовые строки — это общий случай и Вы можете у себя в коде их использовать как угодно.
PS: есть мысль, что 64000 бита на чанк тянутся со времён, когда не было длинных строк. А для перехода на новую (большую) длину чанка требовалось бы перегенерировать индексы и подкорректировать пользовательский код, работающий с чанками напрямую, если там есть жёсткая привязка к такой длине. Возможно, когда-то в будущих версиях это и случится.
Не нужно путать максимальную длину битовой строки вообще и длину чанка bitmap-индексов для таблиц в частности.
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.
Можете пояснить, что это за методы в GlobalsDB, которые могут вызывать функции Caché Object Script?
Скорее всего имелось в виду Globals API, а не GlobalsDB: Calling Caché Methods (Using the Globals API)
Ещё нужно учитывать, что не все возможности Globals API поддерживаются в GlobalsDB: Globals API In Caché
В своё время тоже делал свою реализацию протокола WebSocket средствами СУБД Caché, правда для 76 и 07 версии.
Но с внедрением нативной поддержки RFC 6455 необходимость в велосипеде отпала.
Сделал небольшой тест (для ускорения заполнения таблицы использовал не SQL, а прямой доступ). Время везде приводится в секундах.
{
Index idxClicks On clicks [ Type = bitslice ];
Property d As %Date;
Property browserid As %Integer [ Required, SqlFieldName = browser_id ];
Property bannerid As %Integer [ Required, SqlFieldName = banner_id ];
Property views As %Integer;
Property clicks As %Integer;
ClassMethod Fill()
{
set time=$zhorolog
set succ(0)=0
set succ(1)=0
set succ(2)=50
set succ(3)=500
set insucc(0)=0
set insucc(1)=0
set insucc(2)=400
set insucc(3)=400000
do DISABLE^%NOJRN
do ..%KillExtent()
set i=0
for d=$horolog-99:1:$horolog {
for browserid=0:1:99 {
for bannerid=0:1:999 {
set succ=succ($random(4))
set insucc=insucc($random(4))
set i=i+1
set ^demo.testD(i)=$listbuild("",d,browserid,bannerid,succ+insucc,succ)
}
}
}
set ^demo.testD=i
do ENABLE^%NOJRN
write "Время заполнения таблицы = ",$zhorolog-time,!
do ..%ConstructIndicesParallel(,,,1,,0,0)
}
}
Результаты на моей машине (i5-2400, ST3500413AS):
TEST>do ##class(demo.test).Fill()Время заполнения таблицы = 5.327899Время построения индекса, используя 4 процесса = 15.495457select sum(clicks) from demo.test -- время = 0.031
Вот правильная ссылка: www.microsoft.com/ru-ru/events/ep/vs2013_anounce/
Тот, за который отвечает сама Caché и который используется движком SQL и DeepSee (для MDX-запросов) для ускорения запросов.
А если свои bitmap-индексы будете использовать с длиной >64000 бит, то да — может пригодиться
Необязательно ждать новой версии, чтобы исправить ошибку в уже существующей.
По самой статье будут вопросы?
Чанки используются в таблицах для хранения bitmap/bitslice индексов и за их формированием и использованием следит сама система.
А битовые строки — это общий случай и Вы можете у себя в коде их использовать как угодно.
PS: есть мысль, что 64000 бита на чанк тянутся со времён, когда не было длинных строк. А для перехода на новую (большую) длину чанка требовалось бы перегенерировать индексы и подкорректировать пользовательский код, работающий с чанками напрямую, если там есть жёсткая привязка к такой длине. Возможно, когда-то в будущих версиях это и случится.
Ещё можете посмотреть в исходниках значение $$$DeepSeeBitsPerChunk, BitsPerChunk, $$$BitMapSize.
Не хватает где: на хабре или вообще?
Если вообще, то материалов предостаточно, например:
Как говорится, читать — не перечитать.
Эх, а я думал Вы догадаетесь сами по моему профилю.
И сравнение по скорости запросов чистого SQL с Вашим решением тоже не помешало бы.
PS: сам использую СУБД, нативно поддерживающую ООП (не только для Python), SQL и NoSQL, поэтому и вопросов с ORM не возникает.
Ещё нужно учитывать, что не все возможности Globals API поддерживаются в GlobalsDB: Globals API In Caché
Я пока так и не увидел подтверждения на основе открытых официальных источников ваших слов:
Кулуарная информация меня не интересует.
А специально куда-то писать, чтобы узнать эту информацию, как вы мне советуете, я не собираюсь. И не только поэтому.
Но с внедрением нативной поддержки RFC 6455 необходимость в велосипеде отпала.