The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Стабильный релиз MySQL хранилища InfiniDB 1.0

02.02.2010 22:05

Представлен первый релиз InfiniDB, нового хранилища для MySQL 5.1.x, предназначенного для организации обработки и выполнения аналитических запросов над большими массивами данных (Data Warehouse). InfiniDB подходит для создания хранилища для средств бизнес-аналитики, организации систем генерации отчетов и использования в программах с интенсивным чтением данных из БД. Слабое место InfiniDB - производительность добавления данных. Исходные тексты разработки распространяются в рамках лицензии GPL v2.

В отличие от других хранилищ, InfiniDB хранит данные не построчно, а с разбивкой по столбцам, что позволяет оптимизировать выполнение группировки по столбцам из БД большого размера (сотни гигабайт). Особенно эффективен подобный подход, когда данные в столбцах повторяются. Кроме построчного хранения с целью оптимизации операций ввода/вывода в InfiniDB поддерживается автоматическое вертикальное и горизонтальное партицирование больших таблиц, позволяющее логически распределять данные по хранилищам в привязке к диапазонам хранимых значений. При партицировании не требуется ручное проектирование схемы БД или определение места размещения хранилищ.

Другие особенности InfiniDB:

  • Многопоточная организация работы, позволяющая максимально использовать ресурсы многоядерных систем;
  • Поддержка выполнения множества одновременных запросов, лимит выполнения конкурирующих запросов ограничен только мощностью сервера;
  • В комплект входит специальный инструмент для отдачи больших объемов данных с высокой скоростью;
  • Поддержка всех DML операций (insert, update, delete);
  • Поддержка ACID-совместимых транзакций и система обнаружения взаимных блокировок (deadlock);
  • Предоставление средств для автоматического восстановления базы в случае сбоя системы (например, внезапного отключения питания);
  • Мультиверсионный (MVCC) дизайн позволяет избежать блокировки при чтении данных, всегда отдается текущий "снапшот" состояния, одновременно вносимые изменения будут отражены уже в другом снапшоте;
  • Отсутствует необходимость в создании индексов, так как индексация при вертикальном и горизонтальном партицировании производится автоматически;
  • Поддержка конструкции по изменению налету структуры таблиц (ALTER TABLE);
  • Прозрачное сжатие с выбором метода сжатия в зависимости от типа хранимых данных;
  • Набор средств для диагностики производительности, формирования подсказок по тюнингу, выполнения трассировки для выявления неоптимальных SQL запросов;
  • Реализация в виде обычного MySQL-хранилища, подразумевает возможность прозрачного использования во всех приложениях, поддерживающих MySQL.


  1. Главная ссылка к новости (http://infinidb.org/infinidb-b...)
  2. OpenNews: Сравнение производительности специализированных БД InfoBright, InfiniDB и LucidDB
  3. OpenNews: Вышел альфа-релиз InfiniDB, нового хранилища для MySQL
  4. OpenNews: Представлена СУБД MariaDB 5.1.41
  5. OpenNews: Infobright и Talend представили решение для создания хранилищ данных предприятия
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/25267-infinidb
Ключевые слова: infinidb, database, warehouse, mysql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (18) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Kaiser (ok), 04:27, 03/02/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    #  Отсутствует необходимость в создании индексов, так как индексация при вертикальном и горизонтальном партицировании производится автоматически;

    Как это? А какой индекс создастся: лоакльный на каждой партиции или глобальный на всей таблице? А если партицирую по дате (заключения договора), что вероятнее всего,  а индекс нужен на номере договора и еще много где, но не на дате.

    Может быть просто для реализации партицирования используется индекс? Только вот зачем?

     
     
  • 2.2, ACCA (ok), 07:39, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По ходу индекс вообще не создаётся. Обычное дело в Data Warehouse - если у тебя 99+% запросов приводит к full table scan, то тебе индексы - как велосипед Электронику.
     
     
  • 3.18, Kaiser (ok), 15:58, 04/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >По ходу индекс вообще не создаётся. Обычное дело в Data Warehouse -
    >если у тебя 99+% запросов приводит к full table scan, то
    >тебе индексы - как велосипед Электронику.

    99% запросов - это сильно сказано, гораздо меньше и не всех таблиц. И смотря какой full scan. Зачем выбирать данные за 1999 год, когда в большинстве отчетов понадобятся последние несколько кварталов - тут партиции помогут существенно.

    Индексы все же очень нужны - часто лучше соеденить куски нескольких таблиц, нежели денормализовать все в одну большую fact table. Не говоря уже о других типах индексов (bitmap индексы), без которых сложно себе представить хранилище данных.

    Конкретный пример из банковской сферы: посчитать кредитную задолжность по группе взаимосвязных клиентов: нужно из таблиц выбирать данные только по нескольким клиентам, а не по всем - тут без индексов все встанет.


     
  • 2.5, dev (??), 09:55, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    может просто почитать материалы?
     
     
  • 3.16, Kaiser (ok), 04:30, 04/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Automatic vertical and horizontal partitioning: In addition to being column-oriented, InfiniDB also uses a form of logical horizontal range partitioning that does not require special storage placement or schema design. Using both vertical and logical horizontal range partitioning allows InfiniDB to reduce I/O in both directions (column and row).

    Да, индексов не вижу.

     

  • 1.3, Аноним (-), 08:59, 03/02/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Непонятно, как же постгрес обходится без всего этого зоопарка хранилищ.. А в мускуле по сути под каждую задачу есть своё оптимизированное под неё хранилище.
     
     
  • 2.4, pro100master (ok), 09:50, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы бы еще оракл привели :))) Как показывает жизнь, специализированные решения почти всегда лучше комбайнов-универсалов.
     
     
  • 3.6, Аноним (-), 11:32, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Оракл - закрытый монстрообразный продукт.

    А мускул с постгресом - оба вполне себе свободны, оба с достаточно прямой и понятной для разработчиков архитектурой, но различные хранилища клепают только под мускул.

     
     
  • 4.7, pro100master (ok), 13:03, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > но различные хранилища клепают только под мускул

    это упрёк? В таком случае, вы наверное и кучу встраиваемых в постгре языков считаете недостатком и возмущаетесь, ага? Я считаю это - дополнительное преимущество, которое позволяет эффективнее решать задачи, предусмотренными для этого хранилищами :)))

     
     
  • 5.8, Аноним (-), 14:34, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > это упрёк?

    Ни в коем разе, Вы что, как раз наоборот.

    А интересуют причины. Почему под мускул разрабатывают различные хранилища, а под постгрес нет? Мускул проще для разработчика? Или в постгресе и так всё хорошо? Или лицензия не нравится? Или что?

     
     
  • 6.9, pro100master (ok), 15:44, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что у мускула есть интерфейс плагинов. Если человеку дать дубину - он ищет ей различные применения :)))
    Кстати, у постгре тоже фишка есть - встраиваемые языки. Они тоже не остановились на одном языке.
     
     
  • 7.10, pavlinux (ok), 19:15, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Если человеку дать дубину - он ищет ей различные применения :)))

    А какое основное применение дубины? :)

     
     
  • 8.11, XoRe (ok), 19:27, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Создать согласие с мнением хозяина дубины ... текст свёрнут, показать
     
     
  • 9.15, pavlinux (ok), 01:39, 04/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Следовательно не дубина виновата, а хозяин ... текст свёрнут, показать
     
     
  • 10.17, XoRe (ok), 09:47, 04/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В случае дубины - да Но это издержки аналогии ... текст свёрнут, показать
     
  • 8.14, hate (ok), 20:31, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Усиленная аргументация ... текст свёрнут, показать
     
  • 3.13, crypto5 (?), 19:41, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы бы еще оракл привели :))) Как показывает жизнь, специализированные решения почти
    >всегда лучше комбайнов-универсалов.

    Дык у оракла есть компоненты для ОЛАП хранилищ!

     
  • 2.12, crypto5 (?), 19:40, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Непонятно, как же постгрес обходится без всего этого зоопарка хранилищ.. А в
    >мускуле по сути под каждую задачу есть своё оптимизированное под неё
    >хранилище.

    Наверное поэтому постгрес и не рационально применять для ОЛАП задач.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру