Bitcoin Forum

Local => Кодеры => Topic started by: ichai on January 25, 2014, 12:20:16 PM



Title: NoSQL в обработке шар
Post by: ichai on January 25, 2014, 12:20:16 PM
Кто-нибудь думал о том чтобы на пуле хранить шары не в 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!

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


Title: Re: NoSQL в обработке шар
Post by: SonkoDmitry on January 25, 2014, 12:28:35 PM
носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии


Title: Re: NoSQL в обработке шар
Post by: icreator on January 26, 2014, 03:21:37 PM
носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии

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

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


Title: Re: NoSQL в обработке шар
Post by: tvv on January 26, 2014, 04:59:53 PM
Очень тонко подмечено ;)


Title: Re: NoSQL в обработке шар
Post by: SonkoDmitry on January 28, 2014, 10:52:26 AM
носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии

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

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

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


Title: Re: NoSQL в обработке шар
Post by: icreator on January 28, 2014, 06:16:28 PM
да вроде я не о том
просто смысл делать интерпретатор интерпретатора интепртаторов через SQL

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


Title: Re: NoSQL в обработке шар
Post by: Balthazar on January 28, 2014, 07:52:04 PM
Всегда веселили высказывания о "тупом SQL", который "не нужен". Господа специалисты по реляционным СУБД, да будет вам известно, что самая большая и нагруженная БД в мире работает на PostgreSQL. :D

ты думаешь там внутри поле интерпретации скл-запроса там не куча циклов-выборок?? ошибаешься
Выполнение SQL запроса уже лет 30 как перестало быть просто интерпретацией. Вылезай из криокамеры.  ::)

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


Title: Re: NoSQL в обработке шар
Post by: SonkoDmitry on January 29, 2014, 03:39:01 AM
Всегда веселили высказывания о "тупом SQL", который "не нужен". Господа специалисты по реляционным СУБД, да будет вам известно, что самая большая и нагруженная БД в мире работает на PostgreSQL. :D

ты думаешь там внутри поле интерпретации скл-запроса там не куча циклов-выборок?? ошибаешься
Выполнение SQL запроса уже лет 30 как перестало быть просто интерпретацией. Вылезай из криокамеры.  ::)

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