| 1.2, i (??), 12:36, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
гарантирует транзакционную целостность данных это хорошо...
Сравнили бы с ораклом, там с увеличением CPU все нормально.
| | |
| 1.5, tester777 (?), 13:10, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вот только я так и не понял как написать клиентское приложение для работы с данной СУБД на языках отличных от Java, т.е. на C/C++? На сайте нет ни слово про это, да и в SVN примеры только на Java
| | |
| |
| |
| 3.53, tester777 (?), 10:13, 27/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >и для каких задач вы будете использовать такую СУБД на С/С++?
Для начала хочеться посмотреть как оно работает, а с Java на знаком...
| | |
|
|
| 1.6, letsmac (?), 14:00, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хомячкам на заметку - ORACLE это OLAP база. А тут примитивный OLTP, даже вложенных запросов не поддерживает.
| | |
| 1.7, Аноним (-), 14:15, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
Ну круто, только это уже почти вчерашний день. Будущее за полностью распределёнными системами. Пример: на такой штуке можно было бы сделать мега-масштабируемый торрент-трекер. Но зачем? Если и так само движется к magnet-ссылкам и DHT.
| | |
| |
| 2.25, аноним (?), 17:38, 26/05/2010 [^] [^^] [^^^] [ответить]
| +4 +/– |
Сделай Банк\Склад\Accounting\GL\ERP\CRM\OLT\e.t.c. на "magnet-ссылках и DHT"
А если не сделаешь - "Ну круто, только твоя зарплата - это вчерашний день"
PS: Раньше неспособности видеть дальше своего носа стеснялись, а сейчас это типо круто да?
| | |
| |
| 3.31, Аноним (-), 18:20, 26/05/2010 [^] [^^] [^^^] [ответить]
| –4 +/– |
Ты бы не умничал, а сначала подумал. Идея "засунем всё в одну огромную бд, а потом будем думать, как сделать так, чтобы оно ещё и работала" изначально тупиковая. Только представь себе, что вместо множества банков будет один банк, где все счета всех клиентов будут храниться в ОДНОЙ базе, пусть и распределённой по 100000 внутрикорпоративных серверов. К счастью, такого ужаса никогда не будет, т. к. много независимых банков с этим справляются лучше, чем один большой и всемирный. То же самое с интернетом, подумай, почему он расцвёл, а другие сети по-тихому сдулись.
| | |
| |
| 4.45, DeadMustdie (??), 21:20, 26/05/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Только представь себе, что вместо множества банков будет один банк,
> где все счета всех клиентов будут храниться в ОДНОЙ базе
Не самое маловероятное событие, кстати.
Зато никаких проблем со взыскиванием долгов и отслеживанием транзакций.
Мечта большого брата, в сущности...
| | |
|
|
| 2.39, User294 (ok), 19:49, 26/05/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если и так само движется к magnet-ссылкам и DHT.
Ну собссно DHT это по сути этакая гигантская база в стиле key-value из миллионов участников. С достаточно нехилой масштабируемостью, так что за несколько итераций ищется в невъ...нном числе записей + изрядной репликацией так что вылет 1 ноды вообще никто не замечает и это попросту вообще совершенно штатная ситуация.
| | |
|
| 1.8, Lefan (?), 14:17, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 ACID - это не только транзакционная целостность.
Как выполняется "D" без ведения журнала на дисках? Только за счет "автоматической репликации данных внутри кластера" в памяти узлов? Почему-то другие производители, имеющие аналогичную репликацию, считают, что этого не достаточно для Durability и все же реализуют журналирование.
| | |
| |
| |
| 3.10, QuAzI (??), 14:44, 26/05/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
Не бывает идеального железа. И бесперебойники дохнут и блоки питания и рейд-контроллеры.
| | |
| |
| 4.12, Аноним (-), 15:41, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
Так и винты дохнут, и чем тогда журнал тебе поможет? А ещё я могу rm -rf сделать, неужели ACID от этого не защищает?
| | |
| |
| 5.27, аноним (?), 17:46, 26/05/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Хоть тебе это и больно - но всё же попробуй включить моск.
Если поучится - подумай почему пишут журнал даже на системах с ECC RAM + BB RAID + UPS ...
| | |
| |
| 6.41, Sw00p aka Jerom (?), 20:30, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
 ООМ достаточно ))
журналу - да
пс: все данные хранит в ОЗУ - блин это что на одном сервере кроме бд ничего стоять не должно ???
| | |
| |
| 7.52, Taller (?), 02:22, 27/05/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
судя по всему, там на всем кластере кроме БД ничего стоять не должно.
Хотя ОС - это уже кое-что.
| | |
|
|
|
|
|
| |
| 3.13, Lefan (?), 15:42, 26/05/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Конечно не мне рассказывать как делать СУБД. Я всего лишь указал, что в своем обзоре они не до конца раскрывают значение соответствия своей СУБД ACID принципам. Это все смахивает на маркетинг, который ориентирован на таких, как ты, уважаемый "Аноним". Вам достаточно увидеть имя "Mike Stonebraker", чтоб отключить мозг и идти за великим и могучим.
| | |
| |
| 4.18, klalafuda (?), 15:55, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– | |
1.3 How is ACID-compliance achieved?
Durability: VoltDB provides both replication of partitions (known as K-safety) and periodic database snapshots to ensure the availability of the data.
Т.е. снапшотами снапшотами и ещё раз снапшотами. Ну а все, что попало между ними - bad karma.
| | |
| |
| 5.19, Crazy Alex (??), 16:13, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
А репликации разделов ни при чем? Учитывая, что разделы на разных нодах в том числе, т.е. чтобы завалить все реплики (ага, в памяти) надо угробить несколько нод.
| | |
| |
| 6.24, Lefan (?), 17:30, 26/05/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
классическое Durability подразумевает, что после полной незапланированной перезагрузки системы (включая весь кластер, т.к. питание всего ЦОД-а может тоже накрыться)данные подтвержденной транзакции сохраняться.
FYI:
MySQL Cluster тоже имеет автоматическую синхронную репликацию между нодами, но для выполнения условия "D" они вынуждены использовать журнальные логи.
C Mnesia аналогичная ситуация.
Или вы считаете, что Эриксон и создатели MySQL Cluster-а чего-то недопонимают в построение DBMS?
P.S. только не надо сейчас разводить флейм по поводу того, что можно разные узлы кластера посадить на разные UPS-ы и т.д.
| | |
| |
| 7.26, Crazy Alex (??), 17:41, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
Нет, я считаю, что это слишком жесткое требование в 99,9% случаев реального использования. Веротяноть ухода в даун всего кластера вряд ли больше веротяности ошибки в софте, когда кривые данные будут реплицированы и записаны на диск.
| | |
|
|
|
|
|
|
| 1.15, klalafuda (?), 15:53, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> Невероятного на первый взгляд роста производительности в VoltDB удалось добиться благодаря использованию совершенно непохожей на традиционные схемы внутренней архитектуры.
Ээээ...
1.2. What is the architecture of VoltDB?
VoltDB is an in-memory database distributed on a scalable cluster of shared-nothing servers. Transactions are defined as Java stored procedures, using ANSI-standard SQL for data access and using parallel single-threaded processing to ensure transactional consistency while avoiding the overhead of locking, latching, and resource management seen in traditional database systems.
Т.е. основная 'уникальность новой архитектуры' я так понимаю состоит в том, что все данные тупо запихали в память :-? Ну-ну. Очень здорово. Особенно для средних баз в пару-тройку терабайт.
| | |
| |
| 2.29, аноним (?), 17:54, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
klalafuda - там и с вот этим на поверку оказалось не как в рекламе:
> using ANSI-standard SQL for data access
А в реале ЖОСТКИЙ субсет от SQL'я - для реальной работы ... того :(
| | |
| |
| 3.34, Crazy Alex (??), 18:52, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
>klalafuda - там и с вот этим на поверку оказалось не как
>в рекламе:
>> using ANSI-standard SQL for data access
>
>А в реале ЖОСТКИЙ субсет от SQL'я - для реальной работы ...
>того :(
Ну, во-первых - в планах есть расширение понимаемого подмножества. Во-вторых - скажите спасибо, что не NoSQL. В-третьих - как раз для OLP много и не нужно - примитивные запросы/вставки в основном.
| | |
|
|
| 1.17, mef (ok), 15:54, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Это хорошая новость, но как мне попробовать эту DB через php?
| | |
| |
| 2.20, iZEN (ok), 16:19, 26/05/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вам ещё не ясно? PHP нет места в энтерпрайзе. Этот язык создавался для домашних страничек.
| | |
| |
| |
| 4.23, klalafuda (?), 17:24, 26/05/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD. В-третьих, она на них так до сих пор и не работает.
| | |
| |
| 5.43, Sw00p aka Jerom (?), 20:35, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
>
>Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD.
>В-третьих, она на них так до сих пор и не работает.
>
историю прочти - для кофеварок
| | |
|
| 4.54, mike lee (?), 12:05, 27/05/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
не важно что для чего создавалось. суть в том что сейчас Java в интрепрайзе, а пхп нет.
| | |
|
|
| 2.59, XoRe (ok), 01:40, 31/05/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Это хорошая новость, но как мне попробовать эту DB через php?
Написать драйвер для этой ДБ.
В процессе написания напробуетесь)
| | |
|
| 1.36, gennady (??), 19:26, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Однако:
"Все данные постоянно держатся в ОЗУ, что обеспечивает максимальную пропускную способность и исключает необходимость буферизации;"
Т.е. размер базы ограничен размером ОЗУ, отсюда и "рост производительности". Соотношение как раз как между диском и RAM. И то только на операциях чтения, а когда пойдет массированная запись она так же сдохнет уперевшись в механику систем хранения и ограничений скорости шин периферии и обмена с дисками. Особенно в распред.вычислениях, где затраты на синхронизацию и управление весьма кусаются.
"Планы на будущее:
Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);"
В InterBase (ныне FireBird) это было еще лет 10 назад...
PR очередного прожекта?
| | |
| |
| 2.40, funky_dennis (?), 19:54, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);
Особенно интересно, куда денутся те данные которые лежат в этих 32Г оперативы, после рестарта...
| | |
| |
| 3.49, Crazy Alex (??), 21:59, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка
>СУБД);
>
>Особенно интересно, куда денутся те данные которые лежат в этих 32Г оперативы,
>после рестарта...
На диск, куда ж еще. Где большая часть и так находится (ибо снапшотами сброшена).
| | |
|
| 2.44, Sw00p aka Jerom (?), 20:38, 26/05/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>[оверквотинг удален]
>
>"Планы на будущее:
>
>Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка
>СУБД);"
>
>В InterBase (ныне FireBird) это было еще лет 10 назад...
>
>
>PR очередного прожекта?
отсюда один сегфолт и вся память в течке ))
рестартните сервер
пс: тупо и ещё раз тупо всё хранить в памяти
если бы Л2 или Л1 кеши были бы хотя бы в размер с ОЗУ то они умудрились бы и там хранить всё )
| | |
| |
| 3.50, Crazy Alex (??), 22:00, 26/05/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>[оверквотинг удален]
>>
>>PR очередного прожекта?
>
>отсюда один сегфолт и вся память в течке ))
>рестартните сервер
>
>пс: тупо и ещё раз тупо всё хранить в памяти
>если бы Л2 или Л1 кеши были бы хотя бы в размер
>с ОЗУ то они умудрились бы и там хранить всё )
>
при сегфолте умерший процесс отдает память операционной системе ;-)
Ну и оно на джаве, насколько я понимаю - там скорее эксепшн
| | |
|
|
| 1.37, funky_dennis (?), 19:47, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Да йомайо - PR PR PR, TimesTen - абсолютно тоже самое, чуваки писали, что увеличили производительной бекендной базы Oracle в 10 раз, поставив перед ней фронтенд - TimesTen, при этом объясняя ускорение за счет прямой адресации страниц в памяти, ну то есть TimesTen 100% ограничен оперативой.
Ну вот у меня пару сотен гигов данных (по современным меркам - вообще семечки) и два сервера, как мне помогут их поделки?
Я и сам могу написать БД, которая будет работать только с оперативой, периодически делая срач в лог для D из ACID.
Короче, это реклама ораклу, не более.
| | |
| |
| 2.47, DeadMustdie (??), 21:27, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>TimesTen - абсолютно тоже самое
Да, весьма похоже. Только Oracle в плане позиционирования своего детища пограмотнее
будет и поэтому TimesTen в основном рассматривается как прослойка между "реальной"
СУБД и приложением - своего рода ускоритель.
| | |
| 2.51, Crazy Alex (??), 22:05, 26/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
Ну а тут уже написано. И даже SQL понимает какой-никакой. В общем, добавили же софта, а не украли - чего ругаться...
| | |
|
| 1.57, Евгений (??), 11:51, 28/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Это база не попадает в категорию баз "общего назначения".
Отсюда её уникальная скорость.
Да и что понимать под RealTime?
Судя по примерам применения:
Онлайн игры, обрабатывать нужно быстро, но данные не столь критичны. Откат до ближайшего снапшота вполне приемлем.
Онлайн торги: возможно полностью аналогично предыдущему. Данных приходит много, накопление статистики, но сами данные не столь критичны, если будут пропущены.
Т.е. эта штука - решение для весьма узкой ниши.
Вот тока не пойму как они обогнали по производительности MemCache?
| | |
| 1.58, Alex (??), 22:50, 30/05/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
In-memory годятся только для систем, где данных не очень много, и отказ всего кластера по питанию не столь вероятен. Обычно либо первое, либо второе - ибо большие распределенные системы обрабатывают огромное количество данных, а мелкие сосредоточены в одном здании.
Короче говоря вещь интересная, будем посмотреть, но какой-то disk backend ей определенно нужен.
| | |
|
