| |
| 2.2, o (?), 21:55, 25/01/2013 [^] [^^] [^^^] [ответить]
| –15 +/– |
на java. отсяюда и сказки и росказни про недорого.
| | |
| 2.18, VoDA (ok), 12:49, 26/01/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 > Какая-то просто сказка а не СУБД...
Похоже она не реляционная, оттуда и бонусы.
| | |
|
| 1.3, Аноним (-), 22:10, 25/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Все данные каждого узла полностью прокэшированы в ОЗУ...
Не слишком ли жирно?
| | |
| |
| 2.4, Аноним (-), 22:35, 25/01/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Все данные каждого узла полностью прокэшированы в ОЗУ...
> Не слишком ли жирно?
Время сейчас такое, оперативная память стоит не дорого, вот и оптимизация идет за ее счет. На мой взгляд, и SSD уже не такое дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за счет железа. Как бы противоречиво это не звучало, ПО надо проектировать с учетом минимальных системных требований, но с максимальной функциональностью под поставленные задачи. Раньше было слабое железо и все старались писать код оптимально, ковырялись в нем часами, только ради того найти оптимальное решение для максимального быстродействия.
| | |
| |
| 3.23, XoRe (ok), 14:52, 26/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > На мой взгляд, и SSD уже не такое
> дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за
> счет железа.
SSD не панацея.
Неоптимальные алгоритмы могут свести на нет любые бонусы от железа.
Например, если для получения ФИО одного юзера, вы делаете select * from users;
| | |
| |
| 4.27, Аноним (-), 18:59, 26/01/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
>> На мой взгляд, и SSD уже не такое
>> дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за
>> счет железа.
> SSD не панацея.
> Неоптимальные алгоритмы могут свести на нет любые бонусы от железа.
> Например, если для получения ФИО одного юзера, вы делаете select * from
> users;
Так кодируют только м*даки.
| | |
| |
| 5.39, Аноним (-), 12:38, 28/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>> На мой взгляд, и SSD уже не такое
>>> дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за
>>> счет железа.
>> SSD не панацея.
>> Неоптимальные алгоритмы могут свести на нет любые бонусы от железа.
>> Например, если для получения ФИО одного юзера, вы делаете select * from
>> users;
> Так кодируют только м*даки.
А закон Амдала и когерентность кэша тоже так-то никто не отменял.
| | |
| 5.41, slowpoke (?), 14:51, 29/01/2013 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Так кодируют только м*даки.
зато они очень плодовиты, написали уже pulseaudio, systemd...
| | |
|
|
|
|
| 1.5, жабабыдлокодер (ok), 23:31, 25/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Прочитав "JDBC не поддерживается" крайне удивился: все-таки на Java написано... Взаимоисключающие параграфы?
Посмотрел на сайте - ничего подобного, поддерживается, есть нормальные примеры. Ошибка в новости?
| | |
| |
| 2.45, шестиклассник (?), 18:08, 31/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
Не поддерживается напрямую для всей БД. Вместо этого агрегация результатов выполнения на узлах.
| | |
|
| |
| 2.9, rshadow (ok), 03:17, 26/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Все очень просто ... на одной машинке с 64Гб хватит памяти чтоб сохранить 10000 записей. Хочешь больше, ставь больше машинок.
| | |
| |
| |
| 4.28, Аноним (-), 19:00, 26/01/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Вы не поняли части об оперативной памяти.
А вы поняли? Как вы себе представляете ПОЛНОЕ кэширование 1 Тб? А ведь в промышленных реляционных системах это МАЛЕНЬКАЯ база, даже не средняя.
| | |
|
|
| |
| 3.29, Аноним (-), 19:01, 26/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> не нужно иметь много мозгов, чтобы показывать большие tps на контенте в
> оперативной памяти
Покажи мне TPC-D на этой базе. Угумс? С штатными 32 Тб базы. И полной спецификацией, как положено по TPC.
| | |
|
|
| 1.11, Аноним (-), 10:21, 26/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– | |
>Все данные каждого узла полностью прокэшированы в ОЗУ
Что? Нужна БД на терабайт - накидай терабайт оперативы? Джававыродки такие милашки.
| | |
| |
| 2.38, Аноним (-), 12:36, 28/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
>>Все данные каждого узла полностью прокэшированы в ОЗУ
> Что? Нужна БД на терабайт - накидай терабайт оперативы? Джававыродки такие милашки.
Я что-то не припомню, чтобы хоть в каком-нибудь боксе столько памяти видал. Той самой, которая как лопата дерьма стоит. :))))))))))))))))
| | |
|
| 1.13, anonymous (??), 11:26, 26/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
то ли такой хитрый пиар джавы то ли ответление от имеющегося nosql-направления в самом postgresql.
Неожиданно.
| | |
| |
| 2.15, Аноним (-), 11:42, 26/01/2013 [^] [^^] [^^^] [ответить]
| –6 +/– |
Какой к черту пиар джавы? Вы бы себя со стороны слышали. By design гнилая технология, предназначавшаяся для погроммирования кофеварок переучившимися индусскими таксистами. Ни один пиарщик жабу из ее гнойного болота не вытащит.
| | |
| |
| 3.17, anonymous (??), 12:19, 26/01/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Какой к черту пиар джавы? Вы бы себя со стороны слышали. By
> design гнилая технология, предназначавшаяся для погроммирования кофеварок переучившимися
> индусскими таксистами. Ни один пиарщик жабу из ее гнойного болота не
> вытащит.
Вы бы себя со стороны видели как слушаете других или проанализировали собственный недостаток чувства юмора. Мне тоже джава не нравится.
| | |
|
|
| |
| 2.19, VoDA (ok), 12:51, 26/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Не совсем понятно что будет если пара узлов упадёт.
Исходя из фразы данные реплицируются, можно сделать вывод, что кластер выживет.
| | |
| |
| 3.40, Аноним (-), 12:39, 28/01/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Не совсем понятно что будет если пара узлов упадёт.
> Исходя из фразы данные реплицируются, можно сделать вывод, что кластер выживет.
Из этой фразы ничего не следует. Репликация вообще к надежности кластера никакого отношения не имеет, смекаешь?
| | |
| 3.44, Aleks Revo (ok), 23:12, 30/01/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Об этом стоит прочитать подробней не из новости, а из документации
В целом VoltDB - это "in memory" система (а таковые обычно изначально ориентированы на кластер ради надёжности) с минимально возможным количеством блокировок - даже на одной машине поднимается кластер по числу ядер и между ними делается распределение данных и нагрузки на уровне протокола. Скорость работы и линейность масштабирования достигается за счёт распределения данных между узлами и того самого фирменного сетевого протокола, которым авторы, наверно справедливо, гордятся и который позволяет реализовать ACID в кластере, которого все так боятся, ибо "медленно"..
| | |
| |
| 4.46, Аноним (46), 10:14, 06/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Какая разница сколько там чего на одной машине запущено !
Упала железяка и нет кластера и нет ваших данных в памяти...
| | |
|
|
|
| 1.26, piteri (ok), 15:40, 26/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Таак-c.
Явахейтеры увидели в новости слово "java"
Нищеброды увидели в новости предложение "Все данные каждого узла полностью прокэшированы в ОЗУ"
Ваши мнения безусловно интересны.
Но всё же хотелось бы услышать тех, кто видел этот вольт вживую.
| | |
| 1.31, anonymous (??), 21:16, 26/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Все данные каждого узла полностью прокэшированы в ОЗУ
>запускается несколько узлов VoltDB, каждый из которых привязывается к отдельному ядру CPU
оптимизация такая оптимизация
| | |
| 1.36, Pilat (ok), 17:16, 27/01/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Ответы на многие вопросы типа "Как вы себе представляете ПОЛНОЕ кэширование 1 Тб?" есть в FAQ, наверно такого рода вопросы постоянно встречаются у людей, не понимающих, что если серьёзные люди взялись за такую задачу, то не просто ради развлечения.
What is VoltDB's scaling model?
VoltDB automatically partitions frequently accessed database tables across the available cluster nodes. Both the capacity and performance of the database can be increased by adding nodes to the cluster. Upon changes to cluster size, VoltDB automatically redistributes the partitions to the new configuration when you reload the data. VoltDB also allows tables with infrequently-changing data to be replicated to each node to further optimize performance.
Короче говоря, хотите получить терабайтную базу - ставьте 10-15 машин по 128 гигабайт. И получите пол-миллиона TPC.
| | |
|
