|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Проектирую приложение которое помимо прочего должно демонстрировать графики хода котировок валют! сделал бд(Пока MySQL) туда каждую секунду поступает текущая цена на каждую пару валют! Пар валют много так что за час может легко набижать 50000 и более а данные надо собирать на месяцы может более года! Как вы считает подойдёт ли MySQL или стоит смотреть в сторону NOSQL??? Как вариант могу инфу на разные пары по разным таблицам распихать!! Какие будут соображения!?? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 11:53 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Areostar, возможно, Вам нужно посмотреть тему СУБД in memory. Т.е. Вы смотрите разные классы СУБД по типу модели данных. Но есть и классификация по способу хранения. ТО что Вы сотрите - это хранение данных на вторичных носителях. Но я слышал, что для котировок имеют значение in memory. Чтение со вторичных носителей основной тормоз. А котировки вроде подходят для хранения их в ОП полностью. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 12:16 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
AreostarКакие будут соображения!?? Лично я всегда считал и до сих пор считаю, что хранение данных и отображение данных это перпендикулярные задачи. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 12:43 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Ну так что что-то отобразить, эти данные иметь надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 16:01 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
AreostarНу так что что-то отобразить, эти данные иметь надо. Да. Но источником данных не обязана быть БД. Более того, обычно БД - наихудший из возможных источников. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 16:05 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Данные приходится вытягивание собственноручно(правда программно) так что ещё и в Джейсон перекладывать к примеры только время тратить. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 16:36 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Areostar, это не для субд задача, вам явно что-то типа интерфейса к файлику нужно, berkleyDB или какой другой key-value storage ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 16:54 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Yo.!, Спасибо, погуглю ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 17:56 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Стебелек ставь. Из железа хватит китайского чего-нибудь из серии мобайл. Остаточные цифровые мощности можно отдать ритейлерским сетям. А если не отдавать и сам сервак будешь собирать то куллер не ставь, экономь и береги электроэнергию. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 22:19 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Areostarтуда каждую секунду поступает текущая цена на каждую пару валют! Ну это немного. Торгуемых пар не более 100 (в реальности еще меньше), поэтому делать 100 инсертов ежесекундно в БД - раз плюнуть. Тем более что инсерты простые, всего несколько полей. Теперь посчитаем, 100шт/сек * 3600 сек * 24ч * 365 дней = 3 млрд записей. Кластерный индекс по имени + по времени позволит достаточно быстро искать по истории. Запись будет быстрой, так как обычный инсерт. А текущие котировки хранить в отдельной таблице, там будет записей по количеству пар, то есть всего 100. Такая таблица будет закеширована полностью в память. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2016, 10:45 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovAreostarКакие будут соображения!?? Лично я всегда считал и до сих пор считаю, что хранение данных и отображение данных это перпендикулярные задачи. +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2016, 06:34 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Areostarсделал бд(Пока MySQL) туда каждую секунду поступает текущая цена на каждую пару валют! Пар валют много так что за час может легко набижать 50000 и более а данные надо собирать на месяцы может более года! Важно не то, как данные в хранилище попадают, а то, как их оттуда извлекать хочется. Если надо просто писать, то лучший вариант - плоский файл. А вот если читать, то надо смотреть по каким параметрам запросы пойдут. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 17:07 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
AreostarПроектирую приложение которое помимо прочего должно демонстрировать графики хода котировок валют! сделал бд(Пока MySQL) туда каждую секунду поступает текущая цена на каждую пару валют! Пар валют много так что за час может легко набижать 50000 и более а данные надо собирать на месяцы может более года! Как вы считает подойдёт ли MySQL или стоит смотреть в сторону NOSQL??? Как вариант могу инфу на разные пары по разным таблицам распихать!! Какие будут соображения!?? Только заметил - ТС, похоже, был чем-то сильно возбужден при обращении на форуме :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2016, 06:35 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
всем спасибо за ответы ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2018, 21:55 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Спустя 2 года? )))) В принципе согласен, лучше поздно, чем никогда ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2018, 23:13 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Areostarвсем спасибо за ответыуже что-то сделано или только с СУБД определились? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2018, 23:51 |
|
MySQL или NOSQL
|
|||
---|---|---|---|
#18+
Спустя два года стоит отметить что вопрос звучал странно. NoSQL-это не СУБД а целое семейство технологий которые работают с даннымы "по другому". Вобщем MySQL или нечто другое... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2018, 18:08 |
|
|
start [/forum/topic.php?fid=35&msg=39591960&tid=1552220]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 240ms |
total: | 359ms |
0 / 0 |