NoSQL в обработке шар

[ichai]

Кто-нибудь думал о том чтобы на пуле хранить шары не в mysql а в nosql хранилищах. Стоит ли овчинка выделки?

Пример догехауса показывает что на вычисление награды при росте скорости пула не хватит никаких мощностей железа.
https://dogehouse.org/

Code:

Current pool rate : 21.984358 GH/s
PPLNS Blocks left to calculate : 24
Pool is overloaded. Its probably calculating a huge PPLNS round!

У кого какие мысли об этом?

[SonkoDmitry]

носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии

[icreator]

носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии

это не модненькие технологии а изначально все базы данных были такими - DBASE2 FOXBASE ...

тупой SQL придумали для того чтобы лишний раз нагрузить комп и вынудить народ купить более мощной компьютер
всегда ненавидел этот тупой sql

[tvv]

Очень тонко подмечено

[SonkoDmitry]

носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии

это не модненькие технологии а изначально все базы данных были такими - DBASE2 FOXBASE ...

тупой SQL придумали для того чтобы лишний раз нагрузить комп и вынудить народ купить более мощной компьютер
всегда ненавидел этот тупой sql

Мощности возрастают, как следствие, появляется возможность обрабатывать более сложные конструкции. Дак почему вместо того, чтобы делать десять кей-валуе запросов, не сделать один? Ах да, есть еще такой момент как целостность, ибо после получения десятого запроса нет никакой гарантии, что результаты первого до сих пор актуальные. Ставить локи на запись только ради того, что вытащить актуальные значения это путь в бездну. В один прекрасный момент, накопится такая очередь на запись, что даже мощное железо упадет на спинку лапками кверху.

PS: ах да, еще. ни фокспро, ни иные xBASE движки не были кей-валуе, они были прекрасным примером реляционных субд своего времени.

[icreator]

да вроде я не о том
просто смысл делать интерпретатор интерпретатора интепртаторов через SQL

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

[Balthazar]

Всегда веселили высказывания о "тупом SQL", который "не нужен". Господа специалисты по реляционным СУБД, да будет вам известно, что самая большая и нагруженная БД в мире работает на PostgreSQL.

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

Выполнение SQL запроса уже лет 30 как перестало быть просто интерпретацией. Вылезай из криокамеры.  

По сабжу же ответ прост - шары можно посчитать на лету, не сохраняя их куда бы то ни было. Или же обрабатывать текстовые логи, используя традиционные средства для работы с текстом. И работать это будет в сотни раз быстрее NoSQL или реляционных СУБД просто потому, что они не предназначены для такого рода примитивной работы. В БД нужно класть результаты, а не промежуточные данные.

[SonkoDmitry]

Всегда веселили высказывания о "тупом SQL", который "не нужен". Господа специалисты по реляционным СУБД, да будет вам известно, что самая большая и нагруженная БД в мире работает на PostgreSQL.

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

Выполнение SQL запроса уже лет 30 как перестало быть просто интерпретацией. Вылезай из криокамеры. 

По сабжу же ответ прост - шары можно посчитать на лету, не сохраняя их куда бы то ни было. Или же обрабатывать текстовые логи, используя традиционные средства для работы с текстом. И работать это будет в сотни раз быстрее NoSQL или реляционных СУБД просто потому, что они не предназначены для такого рода примитивной работы. В БД нужно класть результаты, а не промежуточные данные.

спасибо тебе добрый человек, за еще один аргумент