Comments 77
>VoltDB опережает по производительности традиционные OLTP СУБД в односерверной конфигурации в 45 раз
>опережает
>Java
tell me moar.
>опережает
>Java
tell me moar.
Я тоже немного не понял. В 45 раз быстрее за счет того, что все хранится в оперативной памяти? А что будет, если вдруг свет вырубят? Ну, и непонятно как быть с по-настоящему большими БД, которые в оперативку не влезут.
Это вот такое, видимо, кино imdb. Сам с таким не сталкивался.
Если вырубят свет, то
То есть возможно вы потеряете данные, но не больше, чем накопилось за время между снапшотами + снапшоты позволят оставшимся после отключения света данным быть целостными.
А по-настоящему большие БД влазят в память благодаря партицированию.
Для сохранения данных на диск используется концепция снапшотов, отражающих срез данных, актуальных на момент создания снапшота
То есть возможно вы потеряете данные, но не больше, чем накопилось за время между снапшотами + снапшоты позволят оставшимся после отключения света данным быть целостными.
А по-настоящему большие БД влазят в память благодаря партицированию.
Суть архитектуры VoltDB в комбинации хранения всех данных в памяти с концепцией распределённой организации и разбиения БД по разделам (партицирование)
А по-настоящему большие БД влазят в память благодаря партицированию.
Суть архитектуры VoltDB в комбинации хранения всех данных в памяти с концепцией распределённой организации и разбиения БД по разделам (партицирование)
Поясни? Каким образом partitioning гаррантирует сохранность данных?
В комментарии на который я отвечал было 2 вопроса: один касался сохранности, второй размеров БД. Само по себе партицирование не гарантирует сохранность данных, а увеличивает пропускную способность.
Тем не менее, есть механизм, позволяющий увеличить сохранность, учитывая кластерную структуру, как уже написали здесь.
Тем не менее, есть механизм, позволяющий увеличить сохранность, учитывая кластерную структуру, как уже написали здесь.
UFO just landed and posted this here
что такое «moar»?
«исчо»
tell me moar
аффар, пеши исчо :)
tell me moar
аффар, пеши исчо :)
интернет мем, на всяких чанах особенно популярен — lurkmore.ru/Moar
UFO just landed and posted this here
thedailywtf.com/Articles/Announcing-APDB-The-Worlds-Fastest-Database.aspx для желающих истошно расхохотаться.
это все конечно хорошо и красиво, но что если у меня база в несколько террабайт, где я им столько памяти нарисую. или мне предлагается сделать кластер на 100500 серверов?
UFO just landed and posted this here
>Не понимаю я, почему в штыки воспринимаете так это всё. Какие-то поверхностные суждения без вникания в технологию.
Наверное потому что статья поверхностная.
Наверное потому что статья поверхностная.
Причем тут шаред хостинг, у меня выделенный Oracle RAC. А теперь что мне даст ваша СУБД? У меня нет и близко памяти 4 терабайта держать в них. Даже каких то жалких 400 гигов памяти не хватит держать.
я думаю, раз такие пироги, эта база достаточно умна, чтобы закидывать в память не все данные, если ее не хватает. проанализировать и понять, что чаще всего нужно — я думаю, разработчики это сделали.
это во-первых, а во-вторых — у вас много баз весом в террабайт?
даже у какой-нибудь популярной онлайн-игры база вряд-ли будет весить больше 20—30Гб.
а учитывая то, какой кластер нужен будет для обеспечения игры такого масштаба — то это сущие мелочи. 32Гб на узел — нынче таким никого не испугаешь.
и в третьих — в 90% (если не больше) случаев базы сайтов занимают до 100мб. ну до 200мб.
при этом для сайта с такой базой уже нужен какой-нить VPS, а это, как правило, минимум 512мб памяти (у Воли у самого дешевого сразу гиг, например).
Так что не нужно столь драматизировать и пытаться использовать вещи для того, для чего они не предназначены
это во-первых, а во-вторых — у вас много баз весом в террабайт?
даже у какой-нибудь популярной онлайн-игры база вряд-ли будет весить больше 20—30Гб.
а учитывая то, какой кластер нужен будет для обеспечения игры такого масштаба — то это сущие мелочи. 32Гб на узел — нынче таким никого не испугаешь.
и в третьих — в 90% (если не больше) случаев базы сайтов занимают до 100мб. ну до 200мб.
при этом для сайта с такой базой уже нужен какой-нить VPS, а это, как правило, минимум 512мб памяти (у Воли у самого дешевого сразу гиг, например).
Так что не нужно столь драматизировать и пытаться использовать вещи для того, для чего они не предназначены
Там где есть многотерабайтные базы данных, распределённая обработка их особенно актуальна.
Когда несколько дней назад начала распространяться информация про VoltDB, сразу же пошёл смотреть, что за зверь. Слишком быстро выяснилось, что в очередной раз надежда не оправдалась.
Когда несколько дней назад начала распространяться информация про VoltDB, сразу же пошёл смотреть, что за зверь. Слишком быстро выяснилось, что в очередной раз надежда не оправдалась.
UFO just landed and posted this here
Базы данных только для сайтов используются?
32Гб? У меня скоро дома столько будет стоять :) Что за объем для сервера? :)
А чем вы сейчас пользуетесь?
Я почитал описание, ограничения на память в ноде там нет. Если у вас несколько терабайт — то 12 нод по 256Гб даст вам уже 3 терабайта. Главное, чтобы ваши таблицы можно было partitioning.
Данная БД скорее должна использоваться как оперативная, а уже срезы, аналитика и история могут перекочёвывать в более традиционные хранилища. Вы же не делаете запросы по всем своим террабайтам данных? А если делаете то у вас скорее кластер, что для Вольта, по идее, родная среда…
>поддерживает выполнение запросов на языке SQL
>Работа с данными осуществляется через хранимые процедуры на языке Java, копии которых прикрепляются к каждому из разделов (ODBC/JDBC и прямое выполнение SQL-операторов для всей базы не поддерживается)
вот тут можно немного пояснений?
>Работа с данными осуществляется через хранимые процедуры на языке Java, копии которых прикрепляются к каждому из разделов (ODBC/JDBC и прямое выполнение SQL-операторов для всей базы не поддерживается)
вот тут можно немного пояснений?
VoltDB automatically partitions database tables across the available cluster nodes. Both the capacity and performance of the database can be increased by adding nodes to the cluster. VoltDB automatically redistributes the partitions to the new configuration when you reload the data.
VoltDB distributes the rows across the partitions using a hash partitioning scheme. The user identifies, for each partitioned table, which column is used as input to the internal hashing function. Note that not all tables have to partitioned; you can choose to replicate smaller lookup (read-intensive) tables.
Официальная дока
VoltDB distributes the rows across the partitions using a hash partitioning scheme. The user identifies, for each partitioned table, which column is used as input to the internal hashing function. Note that not all tables have to partitioned; you can choose to replicate smaller lookup (read-intensive) tables.
Официальная дока
Вещь в себе. Нету SQL-клиентов кроме как для erlang'а. Доки по протоколу тоже не ощущаю.
UFO just landed and posted this here
Будущее за открытым совтом. Больше баз данных, красивых и разных!
Какие-то сомнительные цифры с точностью до одной транзакции.
На каком сервере тестировалось? Какая структура БД? Какие запросы?
На каком сервере тестировалось? Какая структура БД? Какие запросы?
> VoltDB обработала 53 тысячи транзакций в секунду на одном сервере, в то время как другие СУБД на том же оборудовании могли выполнить только 1155 транзакций.
Интересно, а если измерять производительность, скажем, сутки.
Как сильно будет тормозить механизм снапшотов?
Интересно, а если измерять производительность, скажем, сутки.
Как сильно будет тормозить механизм снапшотов?
По первому впечатлению от документации — мощная штука. Но, не то, чтобы на любителя. В смысле — любитель с ней (IMHO) не справится.
Аппаратные требования — 2 и больше ядер (от 8 для оптимальной производительности)
Память — от 4 Гб
Каждой таблице сопоставляются процедуры, содержащие SQL и дополнительные обсчеты этого SQL. Фактически — каждой таблице соответствует класс Java, отвечающий за все манипуляции с таблицей.
Производительность достигается за счет партиционирования таблиц, отказа от постоянного журналирования и хранения транзакции в ОЗУ.
Крайне специфическое применение (во всяком случае — на текущий момент)
Есть шанс, что через пару-тройку версий их этой штуки может поллуиться нечто более, чем юзабельное (Может быть, уже получилось — но тут надо пробовать.)
Аппаратные требования — 2 и больше ядер (от 8 для оптимальной производительности)
Память — от 4 Гб
Каждой таблице сопоставляются процедуры, содержащие SQL и дополнительные обсчеты этого SQL. Фактически — каждой таблице соответствует класс Java, отвечающий за все манипуляции с таблицей.
Производительность достигается за счет партиционирования таблиц, отказа от постоянного журналирования и хранения транзакции в ОЗУ.
Крайне специфическое применение (во всяком случае — на текущий момент)
In other words, VoltDB's target audience is what have traditionally been known
as Online Transaction Processing (OLTP) applications
Есть шанс, что через пару-тройку версий их этой штуки может поллуиться нечто более, чем юзабельное (Может быть, уже получилось — но тут надо пробовать.)
Ну вообще-то большая часть приложений (тех же сайтов) как раз рассчитаны на OLTP.
Судя по документации, имеются в виду высоконагруженные (в самом полном смысле слова «высоко») проекты типа on-line бронирования, продаж или аукционов. Причем — (опять же суда по моим ощущениям — возможно, когда я документацию перечитаю более внимательно, эти ощущения изменятся) не проекты целиком, но именно их транзакционная часть. То есть что-то вроде поддержки только корзины интернет-магазина из расчета 50 килопокупок в секунду.
Нагруженные сайты как раз в большинстве своем живут на грамотном кешировании на всех возможных уровнях.
Самая первая задача при такой оптимизации звучит так: «разгрузить базу».
Самая первая задача при такой оптимизации звучит так: «разгрузить базу».
1) Иметь серьёзную базу данных с гарантией атомарности хорошо, но для enterprise нужен кластер. Что в этом случае с производительностью — не ясно.
2) Само понятие транзакции означает, что по её завершении обязана быть произведена запись на жёсткий диск либо результатов, либо transaction log. Если этого не делать (или делать не каждую транзакцию), то скорость разумеется возрастает, но надёжность сильно падает — БД уже нельзя назвать транзакционной.
2) Само понятие транзакции означает, что по её завершении обязана быть произведена запись на жёсткий диск либо результатов, либо transaction log. Если этого не делать (или делать не каждую транзакцию), то скорость разумеется возрастает, но надёжность сильно падает — БД уже нельзя назвать транзакционной.
2) «Данные автоматически реплицируются внутри кластера, что позволяет добиться высокой доступности и исключает необходимость ведения журнала» — нет необходимости постоянно сбрасывать логи на диск, если упадёт одна нода, данные будут доступны на другой/других.
Если упадут ВСЕ ноды и сразу? Или если нода только одна и она упадёт?
VoltDB achieves durability through intra-cluster and inter-cluster replication. Data is synchronously committed to multiple execution sites within the cluster to provide durability against node failures. Transactions are asynchronously committed between clusters to provide durability against full-cluster failures (e.g., catastrophic data center events).
И правильно. Незачем утруждать себя и читать описание продукта на сайте. Идиоты вроде меня все равно ответят.
И правильно. Незачем утруждать себя и читать описание продукта на сайте. Идиоты вроде меня все равно ответят.
Ключевое слово «asynchronously». Т.е. есть ненулевая вероятность, что СУБД отрапортовала об успешной транзакциии, но на диске ее не будет.
Тогда получается, что эта БД на одной машине не в состоянии обеспечить ACID? точнее именно последний пункт — Durability, говорящий о том что если транзакция закоммичена, то сбой ей уже не страшен. Получается ACID начинается с 2 машин в кластере…
Странное какое-то сравнение с «другими СУБД», которые выдали 1155 транзакций в секунду, все СУБД одинаково 1155??? Напомнило рекламу порошка «круче других в 100500 раз».
А так решение интересное.
А так решение интересное.
Доставляет. Наконец кто-то собрал все _хорошие_ идеи, разбросанные по сотням постоянно появляющихся DBMS, и сделал не просто что-то новое, а что-то новое изначально не мертво-рожденное.
Если команда не сдуется, рынок ждет передел.
Если команда не сдуется, рынок ждет передел.
Если гарантируется «D» (из ACID), то данные полюбому скидываются на диск при записи. Этот момент как они оптимизировали? Что-то нечисто тут со сравнением с другими СУБД.
Результаты TPC тестов есть?
tpc.org
tpc.org
Она ещё в пелёнках эта VoltDB — да, новая СУБД на рынке OLTP, ей понадобятся годы чтобы убедить людей не смотреть в сторону того же MySQL Cluster. То что она обгоняет обычные СУБД которые вообще не предназначены для OLTP это ни о чём не говорит как и цифра в 53к tps, тот же nbd выдавал в тестах уже миллион транзакций в секунду на одной машине, для баз полностью в памяти нет в этом никакой фантастики. А отложенные синки на диск это фрукт в себе, я думаю через полгодика можно будет думать о VoltDB, а пока о ней нужно только читать :)
> VoltDB обработала 53 тысячи транзакций в секунду на одном сервере, в то время как другие СУБД на том же оборудовании могли выполнить только 1155 транзакций
Kdb меряли?
Kdb меряли?
> ориентированная на обработку транзакций в реальном времени (OLTP)
Вообще-то OLTP вовсе не означает «обработку транзакций в реальном времени».
Вообще-то OLTP вовсе не означает «обработку транзакций в реальном времени».
Я так понимаю, что ребята решили пожертвовать Partition-tolerance в обмен на производительность. Непонятно, что будет если одна из нод кластера решит прилечь. Во всех FAQ этот вопрос игнорируется.
Так же интересно посмотреть как происходит JOIN для данных расположенных на разных нодах.
И непонятно что у них с лицензией. На сайте пишут GPL v3, в исходниках встречаются GPL, MIT и BSD.
Так же интересно посмотреть как происходит JOIN для данных расположенных на разных нодах.
И непонятно что у них с лицензией. На сайте пишут GPL v3, в исходниках встречаются GPL, MIT и BSD.
без ссылок на сами тесты «в 45 раз быстрее» и т.п. сложно воспринимать адекватно.
Где бенчмарки? иначе цифры выглядят голословными
UFO just landed and posted this here
А если смонтировать кусок оперативки в качестве диска и в него установить MySQL, то скорость тоже станет в 45 раз быстрее.
А если поступиь как википедия, и поставить зеркала баз на десятке серверов, с одним мастер-сервером, то вот и кластер получится.
А если поступиь как википедия, и поставить зеркала баз на десятке серверов, с одним мастер-сервером, то вот и кластер получится.
Если бы большинство комментаторов прочитали хотя бы статью на википедии про Стойнбрейкера, думаю было бы куда меньше подколов и сомнений.
Я так понял, что вы уже погоняли данную базу.
Интересно сравнение с другими бесплатными базами.
Мы сейчас используем Nexus, интересно было бы сравнить.
Реально о производительности можно говорить только при сравнении на действующих проектах.
Если есть инфа, то просьба поделится.
Заявленные характеристики удивили.
Интересно сравнение с другими бесплатными базами.
Мы сейчас используем Nexus, интересно было бы сравнить.
Реально о производительности можно говорить только при сравнении на действующих проектах.
Если есть инфа, то просьба поделится.
Заявленные характеристики удивили.
Еще одна MongoDB
UFO just landed and posted this here
Sign up to leave a comment.
Представлена новая открытая СУБД