|
|
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток. Сразу скажу новичок... Подскажите пожалуйста с реализацией. Пишу проект, который собирает технологические данные с серверов, агрегирует и вставляет в БД. Сырые данные которые еще не подверглись агрегации в чем лучше хранить, в оперативной памяти, в Protocol Buffers, в XML? Если отталкиваться от количества данных, то ежесекундно будут приходить около 3000 данных, вида double(64) | double(64) | double(64) т.е. 24 байта за информационную единицу, умножив на 3000 получаю 72000 байт в секунду, умножив на 10 минут (столько планирую хранить данные) получаю 41,200 МБ цифра не большая, если что то не упустил. Но я не знаю как это отразится на производительности. Надеюсь понятно объяснил... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 13:47 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Видимо не понятно объяснил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 17:38 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Та понятно, Что смущает? возможность затыка SQL-сервера при таком потоке? Проведите нагрузочный тест, проверьте загрузку сети, диска и процессора SQL-сервера при этом потоке ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 17:43 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Да все понятно. Точно не в XML. Я бы вообще не заморачивался с хранением данных в памяти, а отправлял в бд по факту получения, и аггрегацией в ней же занимался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 17:45 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlov, А в чем проблема в хранении 42 МБ в оперативной памяти? Зачем сложности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 17:46 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
а, или опасаетесь за само приложение? 42 Мб - это немного, даже если еще столько же служебной информации. Больше вопрос, как эти данные обрабатываются, от этого будет зависеть принцип хранения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2014, 17:47 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Antonariy, я тесты не делал, но в статьях и советах на форумах, пишут что не выдержит БД такой поток данных, единовременно если вставлять, проблем якобы не будет, а постоянный инсерт не выдержит. Собираюсь использовать Postgresql. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 11:18 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Ну ок, раз это небольшой объем. Тогда более высоко производительней будет в оперативке хранить, единствено, можно потерять данные при падения приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 11:23 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlovпишут что не выдержит БД такой поток данных, единовременно если вставлять, проблем якобы не будет, а постоянный инсерт не выдержит А пацаны-разработчики биллинга об этом и не знали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 12:38 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlovежесекундно будут приходить около 3000 данных, вида double(64) | double(64) | double(64) Таки да, не каждая СУБД выдержит, если будет поток 3000 транзакций в секунду. С другой стороны для такого небольшого объема данных нет проблем делать ежесекундную вставку данных одной операцией. Что за СУБД? И какое под ней железо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 13:53 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Arm79, СУБД: PostgreSQL, железо пока CPU: Intel i3, RAM: 4ГБ, при продакшн железо скорей всего изменится в лучшую сторону. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 17:25 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlov, А вот если немного изменить вопрос, объем данных пару гигабайт, ускорить частоту приема на 4, в случае смерти приложения сохранять данные, делать различные срезы из полученной информации... без за базы ????? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 17:50 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlovжелезо пока CPU: Intel i3, RAM: 4ГБ, при продакшн железо скорей всего изменится в лучшую сторону У меня ноут мощнее :-) Ну смотрите, ежесекундно 3000 * 24 байта = 70 килобайт. В общем, ничтожно мало. Есть варианты. Например, генерить multiple инсерты типа: PostgreeSQL DocsINSERT INTO products (product_no, name, price) VALUES (1, 'Cheese', 9.99), (2, 'Bread', 1.99), (3, 'Milk', 2.99); Или сохранять в файл и buill insert через Copy Насколько критично, если какие-то данные пропадут, не попадут в БД? Например, минутный интервал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 18:54 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Arm79, Спасибо за COPY? не знал. Ну если будут пропадать данные раз в полгода, это еще не критично, а если периодически , то это критично. А почему это cпросили, то что команда COPY может не отработать из за ошибки в файле? Еще вопросик, команда COPY может брать данные с RAM? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 21:05 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlov, 1) Создание файла и запись в него килобайтов/мегабайтов ныне не составляет проблем по скорости. Диски быстрые, кэш большой. Поэтому можно спокойно сначала записать в файл, а потом перекинуть в БД 2) Если уж совсем критично по времени, можно файл создавать на RAM-диске. Но у меня все равно чувство, что вы переусложняете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 21:29 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Arm79, Спасибо, буду пробовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 21:45 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlov, в четвертом появился MemoryMappedFile можно работать с привязкой к диску можно чисто с памятью ( быстрее) при мелких размерах, система ставит по дефолту размер кластера диска, делаем рентабельную очередь, с конца пишем данные из разных потоков, с морды заливаем в файл, если есть желании через дельту или как флешем проталкиваем данные на жесткий диск, можно заталкивать структуры (имхо не забывать про смещение), таки получать их из файла, и тд...... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 23:24 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
наверно лучше вместо - ставит по дефолту размер кластера диска, выравнивает до размера клястера.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2014, 23:41 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Коллеги, а что мешает собирать данные в одном потоке, а записывать в базу в разных потоках? Разнести задачу записи в очередь из нескольких потоков и пусть пишут. Хоть через файл, хоть напрямую... Тут вопрос в другом: ежели за 10 минут набегает ~41 Mb данных, то за сутки получим ~5 Gb, за год более 2 Tb без учёта служебных данных и т.д., и т.п. Какова должны быть ретроспективная глубина хранения данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 08:07 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlov10 минут (столько планирую хранить данные) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 09:15 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Shocker.Prodarlov10 минут (столько планирую хранить данные)Shocker.Pro, я помню про 10 минут. Просто меня смутила фраза: автор...Ну если будут пропадать данные раз в полгода, это еще не критично, а если периодически , то это критично... Не сразу понял что речь идёт именно о 10-ти минутном "куске" сырых данных. Видимо, сказывается то, что голова побаливает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 11:00 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Alex Kuznetsov, Я так и планирую разделить по потокам, как раз для промежуточного хранения массива данных я и интересуюсь что использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 11:14 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Где-то в степи, Спасибо за MemoryMappedFile, беру на заметку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 11:15 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlovAlex Kuznetsov, Я так и планирую разделить по потокам, как раз для промежуточного хранения массива данных я и интересуюсь что использовать.Тогда действительно можно посмотреть в сторону MMF. Только учтите один немаловажный момент про размер блоков . MSDN... One advantage to using MMF I/O is that the system performs all data transfers for it in 4K pages of data. ... Правда это было актуально для 1998 года. Сейчас ситуация изменилась и размер страницы зависит от системы. ММF можно использовать для "скидывания" сырых данных на диск, а затем уже в отдельных потоках(после 10-ти минутного скидывания) спокойно сливать данные в базу. Слил в базу - грохнул файл. Таким образом может быть два потока на запись в MMF(не думаю, что для записи секундных данных нужно будет более одного потока), и сколько нужно для передачи файла в базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 12:00 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Alex Kuznetsov, да забудь те вы о много поточном инсерте в базу.... если вытесняющую многозадачность можно победить для такой невьебенной задачи дополнительным клястером то база ну никак не будет писать в таблицу разными потоками.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 13:19 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Где-то в степиAlex Kuznetsov, да забудь те вы о много поточном инсерте в базу.... если вытесняющую многозадачность можно победить для такой невьебенной задачи дополнительным клястером то база ну никак не будет писать в таблицу разными потоками..Коллеги, извините, если ввёл в заблуждение своей фразой "... сколько нужно для передачи файла в базу.". Я имел в виду по одному потоку на файл, а никак не пучок потоков на один файл. Понятно, что один такой файл можно будет слить в базу менее чем за 10 минут. Просто идея в том, чтобы отделить заливку в базу от получения данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 13:32 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
A есть ли выгода в многопоточности? На много увеличится производительность? Где то попадалось что в каждый момент времени выполняется только один поток и бывает проигрыш из за постоянного переключения потоков. К примеру, 5 серверов с которых сливаются данные по TCPIP для каждого создаю поток т.е. 5 потоков, каждый поток пишет свой файл и производит выборку с сервера. Много ли выиграю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 20:49 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlovA есть ли выгода в многопоточности? На много увеличится производительность? Где то попадалось что в каждый момент времени выполняется только один поток и бывает проигрыш из за постоянного переключения потоков. К примеру, 5 серверов с которых сливаются данные по TCPIP для каждого создаю поток т.е. 5 потоков, каждый поток пишет свой файл и производит выборку с сервера. Много ли выиграю?Зависит от количества ядер процессоров. При наличии к примеру четырёх ядер можно распределить к четыре потока каждый на отдельное ядро. Как Вы думаете, при этом будет выигрыш по производительности? А кстати, сервер БД, куда потом будут сливаться обработанные данные, он на отдельной машине или на той-же? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 21:03 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Alex Kuznetsov, А если 5 потоков 4 ядра, как будет выполняться? БД на той же машине. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 21:10 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlovAlex Kuznetsov, А если 5 потоков 4 ядра, как будет выполняться? БД на той же машине.Вы меня проверяете что-ли? Будет выполнять ровно так, как Вы нарисуете. Сможете запустить потоки на разных ядрах, значит три будет работать "отдельно" каждый в отдельном ядре, а два будут "разделять" одно ядро. В какой момент какой именно из этих двух потоков быстрее завершит свою работу, этого Вам даже дядюшка билли не скажет, ибо в винде вытесняющая многозадачность, "кончил, не кончил - три минуты"... В .Net, кстати, не так уж просто заставить поток Thread исполняться на каком-то определённом ядре, тем не менее возможно . БД на той-же машине... хм... "и мы ещё боремся за звание образцовой культуры быта" ... Сливать данные туда-же где будет и так нагружена дисковая подсистема... Я бы подумал над тем, чтобы вынести БД на отдельный сервер... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 22:08 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Alex KuznetsovВы меня проверяете что-ли? Нет, просто вытесняю недопонимание. Alex KuznetsovЯ бы подумал над тем, чтобы вынести БД на отдельный сервер... Пока на одной машине, при продакшене и понижении производительности буду думать насчет второй машины. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2014, 22:24 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
darlov, что-то вы усложняете, 40мб за 10 мин (70кб/сек) - это "ни о чем" даже для не очень мощного компа. копите в памяти, и то что собрали - раз в минуту другим потоком, как вам уже подсказали, формируете групповой Insert. Комп все успеет. Делал схожую систему, и когда симуляцией нагружал диким потоком UDP пакетов - даже на не очень мощном компе все работало с загрузкой проца не более 60%. При таком потоке данных, не уверен что стоит кэшировать все в файл перед заливкой в БД. 5 TCP - мне кажется, если делаете асинхронный прием данных, то принципиальной разницы между одним потоком и пятью не будет. Возможно стоит для каждого TCP просто делать свою очередь (очередь А). Поток заливающий в БД, должен лочить А, быстренько выгружать данные в свою очередь (Б) и отпускать очередь А чтоб туда мог продолжить писать TCP, и уже после из очереди Б формировать данные для загрузки. Симулируйте нагрузку, и там поймете как часто надо в БД писать, и на сколько большими порциями. Также разделите во времени очистку в базе старых данных, с заливкой новых. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2014, 09:02 |
|
||
|
Как лучше хранить сырые данные
|
|||
|---|---|---|---|
|
#18+
Я бы предложил вам протестировать самый быстрый (и самый надежный вариант) если заработает. Тупо инсертить данные по приходу в том виде, в котором приходят без выгрузки их в XML. В крайнем случае - можно их аггрегировать например минуту - и потом одним запросом инсертить. Скорее всего проблемы не возникнет, т.к. данных не так много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 07:54 |
|
||
|
|
start [/forum/topic.php?all=1&fid=20&tid=1403029]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 325ms |
| total: | 476ms |
| 0 / 0 |
