тут конечно все зависит от проекта
на том что сейчас у нас наиболее активный, то там мы имеем более терабайта индексов, индексы занимают больше места чем сами данные.
насчет объема правок, то например журналов в сутки больше может быть в районе 20-40 GB
ну насчет тормозит, тут работаем над быстродействием, совершенства еще не достигли
по сути да, рекомендуемый размер чанка 64000 бит
соответственно наибольшая производительности достигается когда общее количество документов не превышает 64000
у нас большая часть классов документов имеют общий предок и общую нумерацию ID.
и так же мы используем так называемое хранилище для разрезов массива чтобы объединить объекты одного логического функционала в общий битовый массив что позволит с применением разных алгоритмов оптимизации достичь улучшений производительности
так же еще минусом конечно идет разреженность битового массива если в выборку попадет 100 документов и каждый из попадет в отдельный чанк массива, то это конечно очень плохо
да и их тоже но поменьше, их применение это ускорение математических операций
быстро считать количество/суммы
используем для отчетов, когда нужно посчитать сумму значений в нужном поле для выборки документов
да с релевантностью уже сложнее, можно только обойти список документов отсортированному по ID документа.
и чтобы его как то отсортировать нужен сортирующий индекс.
когда чанков стало сотни, т.е. количество объектов в битовом массиве стало миллионы, скорость работы системы стала падать при обработке таких битовых массивов.
Напишу реальный пример, то как используем Bitmap индексы в нашей системе.
Bitmap индексы у нас основные и мы практически не используем стандартные SQL-индексы и вообще SQL
наше приложение это СЭД, большая часть данных представляет собой как и в большинстве систем это документ с набором полей
мы индексируем связь значение свойства название свойства и собственно сам документ, примерно так:
^Index(«FieldName»,«FieldValue»,1)=$bit(0,1,0,1)
соответственно мы можем поискать список документов со значением FieldValue в поле FieldName, и мы получим битовый массив со всеми таким документами. и мы так же мы можем быстро с помощью битовых операций добавить условия поиска документов, в нашей системе это очень удобно и достаточно быстро. Самый большой минус правда, когда количество чанков в битовом массиве становится очень большим.
конечно не проблема, проблема например в конвертации массива битовых строк на уже действующем проекте (когда этот массив может быть несколько сотен гигабайт).
и при запуске нового проекта, знать о таких проблемах
вот-вот, исправлена в версии которая еще не доступна даже в FT.
так что размер битовой строки все же лучше пока ограничивать в 64000 бит
и есть еще один нюанс, данные в БД со стандартным размером блоков в 8Kb, с битовыми строками в 64000 бит и более, не будут кешироваться при работе в конфигурации ECP.
хотя это может быть тоже уже поправлено в будущей версии.
язык может быть ужасен на первый взгляд, но когда поработаешь с ним, уже так не считаешь.
и к тому же цель статей не показать то какой у нас ужасный язык или ради холивара на тему
а показать существующие возможности интересующимся или сомневающимся в возможностях платформы Cache`
так же формировали отчеты для Excel, так же делает это и InterSystems ZEN
но есть некоторые проблемы, такой файл не становиться Excel-форматом, есть некоторые сложности с описанием стиля для числовых ячеек
на такой файл с расширением xls, MS Office с 2010 будет ругаться на ошибку формата и предложит открыть, OpenOffice 3+ открыть откажется
с расширением xlsx, MSOffice открывать откажется ссылаясь на несоответствие расширения его содержимому, а OpenOffice его уже откроет.
в общем хорошо, если бы появилась хорошая поддержка форматов OpenDocument в продуктах InterSystems
весело вы придумали, запретить сокращенные команды и рутины.
А что делать всем разработчикам кто так пишет? что вы скажете делать огромному количеству проектов у которых десятки и сотни тысяч строк кода в рутинах, и классов вообще не используют.
и чем вас не устроили сокращенные команды, пишите сами используя полные команды, откажитесь от макровставок будет вам счастье
и кстати не только олдскульные MUMPS-разработчики используют
— в 2013 студии есть зачатки рефакторинга, переопределение свойств методов и т.д. существуют уже давно
— проблема с автодополнением восполнена с помощью #dim, а если не необязательная типизация то что может быть проблемой для этого, особенности самого языка
— насчет синтаксического контроля это вы зря, он вполне себе нормальный, тем более что ошибок синтаксиса нет так то много для для каше они и объеденнены в одну ошибку SYNTAX, в студии есть проверка на UNDEFINED, (в настройках студии посмотрите как включить)
— есть некоторое форматирование при вводе, например при открытии фигурных скобок, а то что нет возможности отформатировать любой код как это делает тот же netbeans и другие, да это порой неудобно
— насчет отладчика сказать мне что то сложно, пользовался пару раз на поиграться, да и не вижу как его можно улучшить потому как приложения разные (консольные, веб, веб-сервисы) и сложно вообще понять как можно отлаживать удобнее сам язык достаточно предлагает средств для отладки кода. Одно время мне нравилось использовать сбор стека в каше через LOG^%ETN, так я мог просмотреть стек вызовов до нужного мне места и просмотреть как шла нужная переменная через эти вызовы. а так я чаще работаю на своем сервере где веду разработку и просто делаю вывод отладочной информации прямо на страницу приложения.
на том что сейчас у нас наиболее активный, то там мы имеем более терабайта индексов, индексы занимают больше места чем сами данные.
насчет объема правок, то например журналов в сутки больше может быть в районе 20-40 GB
ну насчет тормозит, тут работаем над быстродействием, совершенства еще не достигли
соответственно наибольшая производительности достигается когда общее количество документов не превышает 64000
у нас большая часть классов документов имеют общий предок и общую нумерацию ID.
и так же мы используем так называемое хранилище для разрезов массива чтобы объединить объекты одного логического функционала в общий битовый массив что позволит с применением разных алгоритмов оптимизации достичь улучшений производительности
так же еще минусом конечно идет разреженность битового массива если в выборку попадет 100 документов и каждый из попадет в отдельный чанк массива, то это конечно очень плохо
быстро считать количество/суммы
используем для отчетов, когда нужно посчитать сумму значений в нужном поле для выборки документов
и чтобы его как то отсортировать нужен сортирующий индекс.
Bitmap индексы у нас основные и мы практически не используем стандартные SQL-индексы и вообще SQL
наше приложение это СЭД, большая часть данных представляет собой как и в большинстве систем это документ с набором полей
мы индексируем связь значение свойства название свойства и собственно сам документ, примерно так:
^Index(«FieldName»,«FieldValue»,1)=$bit(0,1,0,1)
соответственно мы можем поискать список документов со значением FieldValue в поле FieldName, и мы получим битовый массив со всеми таким документами. и мы так же мы можем быстро с помощью битовых операций добавить условия поиска документов, в нашей системе это очень удобно и достаточно быстро. Самый большой минус правда, когда количество чанков в битовом массиве становится очень большим.
и при запуске нового проекта, знать о таких проблемах
так что размер битовой строки все же лучше пока ограничивать в 64000 бит
и есть еще один нюанс, данные в БД со стандартным размером блоков в 8Kb, с битовыми строками в 64000 бит и более, не будут кешироваться при работе в конфигурации ECP.
хотя это может быть тоже уже поправлено в будущей версии.
а вот на счет 64000 ссылка
и при этом в исходнике есть
но не описана причина использования такой длины, а это важно было на ранних версиях, не думаю что в последних версиях сильно что изменилось
и к тому же цель статей не показать то какой у нас ужасный язык или ради холивара на тему
а показать существующие возможности интересующимся или сомневающимся в возможностях платформы Cache`
но есть некоторые проблемы, такой файл не становиться Excel-форматом, есть некоторые сложности с описанием стиля для числовых ячеек
на такой файл с расширением xls, MS Office с 2010 будет ругаться на ошибку формата и предложит открыть, OpenOffice 3+ открыть откажется
с расширением xlsx, MSOffice открывать откажется ссылаясь на несоответствие расширения его содержимому, а OpenOffice его уже откроет.
в общем хорошо, если бы появилась хорошая поддержка форматов OpenDocument в продуктах InterSystems
А что делать всем разработчикам кто так пишет? что вы скажете делать огромному количеству проектов у которых десятки и сотни тысяч строк кода в рутинах, и классов вообще не используют.
и чем вас не устроили сокращенные команды, пишите сами используя полные команды, откажитесь от макровставок будет вам счастье
и кстати не только олдскульные MUMPS-разработчики используют
— проблема с автодополнением восполнена с помощью #dim, а если не необязательная типизация то что может быть проблемой для этого, особенности самого языка
— насчет синтаксического контроля это вы зря, он вполне себе нормальный, тем более что ошибок синтаксиса нет так то много для для каше они и объеденнены в одну ошибку SYNTAX, в студии есть проверка на UNDEFINED, (в настройках студии посмотрите как включить)
— есть некоторое форматирование при вводе, например при открытии фигурных скобок, а то что нет возможности отформатировать любой код как это делает тот же netbeans и другие, да это порой неудобно
— насчет отладчика сказать мне что то сложно, пользовался пару раз на поиграться, да и не вижу как его можно улучшить потому как приложения разные (консольные, веб, веб-сервисы) и сложно вообще понять как можно отлаживать удобнее сам язык достаточно предлагает средств для отладки кода. Одно время мне нравилось использовать сбор стека в каше через LOG^%ETN, так я мог просмотреть стек вызовов до нужного мне места и просмотреть как шла нужная переменная через эти вызовы. а так я чаще работаю на своем сервере где веду разработку и просто делаю вывод отладочной информации прямо на страницу приложения.