почему orientdb размеры индекса на диске, так что большой

Question

orientdb 2.0.5

У меня есть база данных, в которой мы создаем, не unque индекс 2 свойств на классе называется indexstat.

Два свойства, которые составляют индекс, являются строковым идентификатором и длинной меткой времени.

Данные создаются партиями по нескольку сотен записей каждые 5 минут. После нескольких часов записи удаляются.

Это список файлов, относящихся к этой таблице.

Вопрос: Почему файл .irs, который согласно документации (связан с неуникальными индексами) ... настолько чудовищно огромен через несколько часов. 298056704 байта больше фактических данных (размер .irs - .sbt size - .cpm size).

Я бы подумал, что индекс будет меньше фактических данных.

Второй вопрос: Что лучше всего здесь. Должен ли я использовать уникальные индексы вместо не-уникальных? Должен ли я найти способ уменьшить данные в индексе (например, использовать longs вместо строк как идентификаторы)?

Ниже приведены имена файлов и их размеры.

indexstat.cpm 727778304 
indexstatidx.irs 1799095296 
indexstatidx.sbt 263168 
indexstat.pcl 773260288 

Это повторяется для нескольких таблиц, где размер индекса больше данных базы данных.

Answer 1

На этом link показана дискуссия относительно файла индекса, возможно, может вам помочь.

Для второго вопроса индекс должен быть выбран в соответствии с вашей целью и вашими данными (а не наоборот). Тип данных (long, string) должен быть тем, который лучше всего представляет ваши поля (и уже здесь, если, например, если вы просто целое число, и этого достаточно для области, бесполезно использовать длинный). Тот же выбор для индекса, если вам не нужно дублировать выбор, будет не уникальным. если вам нужен индекс, который позволяет выбирать диапазон sb-tree вместо хеша и т. д.

Answer 2

Внутренние файлы * .irs, организованные таким образом, что при удалении чего-либо из индекса есть неиспользуемое отверстие осталось в файле. В какой-то момент, когда около половины файлового пространства теряется впустую, эти неиспользуемые отверстия снова появляются в игре и становятся доступными для повторного использования и распределения. Это делается по причинам производительности, чтобы снизить фрагментацию данных индекса. В вашем случае это означает, что рано или поздно файл * .irs перестанет расти, а его максимальный размер должен быть примерно в 2-3 раза больше максимального наблюдаемого размера соответствующего * .pcl-файла, если ваш размер записи одного стата не намного больше по сравнению с размером пары id-timestamp.

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