Comments 13
Спасибо за статью.
Замечу что колонки замечательно и безболезненно можно добавлять, но с удалением не все так просто. Было бы интересно почитать про живой кейс, общая информация это все-таки не то :)
Если говорить о Вертике, то удалять колонки просто нельзя. Но это не является большой проблемой, так как можно просто перестать записывать данные в «ненужные» колонки, и тогда они не занимают места на диске.
Я как раз хочу дать более общую информацию, так как кейсы у всех разные. Но уже опубликовав статью я понял, что даже не написал, что именно за данные мы обрабатываем и как они используются. Исправлюсь в следующей статье.
Я как раз хочу дать более общую информацию, так как кейсы у всех разные. Но уже опубликовав статью я понял, что даже не написал, что именно за данные мы обрабатываем и как они используются. Исправлюсь в следующей статье.
Я не уверен что пустые поля не будут занимать место. Место должно резервироваться чтобы вы могли потом дописать в эти поля и не произошло фрагментации таблицы на диске.
Ключевое отличие Вертики и других специализированных колонко-ориентированных баз данных в том, что таблица на диске не лежит, как таблица. Она лежит, если так можно выразиться, в виде набора колонок. Каждая колонка в своих файлах. Колонки между собой довольно хитро связаны, чтобы можно было восстановить цельную запись. Поэтому пустые поля места не занимают, или занимают, но минимально (один бит плюс число повторений на блок)
А про InfiniDB и Infobright можете сказать что? То есть, что они не прошли отбор — я понял. А вот почему? Медленнее — насколько? В сравнении с чем (TokuDB? Вертика?). По фичам не подходит — что именно?
Мы, конечно, рассчитывали на InfoBright и InfiniDB, потому что они используют MySQL протокол, что упростило бы миграцию.
Насколько я помню, основное принципиальное ограничение InfoBright — это невозможность масштабирования. Это односерверная система. Поэтому мы его серьезно не рассматривали.
InfiniDB мы смотрели более внимательно, концепция выглядела очень многообещающе. В некоторых тестах по производительности он был сравним с GreenPlum, но проигрывал Вертике. Однако на тот момент система была очень сырая (мы пробовали версию 1.0.1-RC1), в частности SQL был не полностью реализован, не поддерживались сабселекты, а также было не возможно использовать в одном селекте и IniniDB, и не-InfninDB (например, InnoDB) таблицы. Возможно, что сейчас продукт стал лучше. Хотя я отслеживаю новости по теме аналитических баз данных, и InfiniDB там давно не встречался.
Насколько я помню, основное принципиальное ограничение InfoBright — это невозможность масштабирования. Это односерверная система. Поэтому мы его серьезно не рассматривали.
InfiniDB мы смотрели более внимательно, концепция выглядела очень многообещающе. В некоторых тестах по производительности он был сравним с GreenPlum, но проигрывал Вертике. Однако на тот момент система была очень сырая (мы пробовали версию 1.0.1-RC1), в частности SQL был не полностью реализован, не поддерживались сабселекты, а также было не возможно использовать в одном селекте и IniniDB, и не-InfninDB (например, InnoDB) таблицы. Возможно, что сейчас продукт стал лучше. Хотя я отслеживаю новости по теме аналитических баз данных, и InfiniDB там давно не встречался.
А что вы думаете про HBASE в качестве хранилища данных?
Мы не пробовали, но из того, что я знаю про HBASE, есть несколько существенных ограничений:
— не поддерживается SQL (эмуляции типа Hive — это слезы)
— трудно, если вообще возможно, получить приемлимую производительность для «простых» запросов, которые должны выполняться быстрее секунды
Кроме того, на момент принятия решения HBase не была доступна, и была очень сырой. Она и сейчас еще сырая.
— не поддерживается SQL (эмуляции типа Hive — это слезы)
— трудно, если вообще возможно, получить приемлимую производительность для «простых» запросов, которые должны выполняться быстрее секунды
Кроме того, на момент принятия решения HBase не была доступна, и была очень сырой. Она и сейчас еще сырая.
Sign up to leave a comment.
Эволюция аналитической инфраструктуры