21 сентября 2016, 11:04
Поделитесь, какую структуру базы данных выбирали для более быстрого доступа(сохранения)потоковых данных? какую организацию данных выбрали и почему?
Поделитесь, какую структуру базы данных выбирали для более быстрого доступа(сохранения)потоковых данных? какую организацию данных выбрали и почему?
18:53
— Газпром ВПЕРВЫЕ поставил партию СПГ в Италию!
— «Макароны с сыром» будут всё равно готовить на русском (противном/ненавистном)- ГАЗе!
Вася Баффет,
Сбербанк все меньше кредитует
В конце тоннеля света нет
Эльвира точно не блефует
Нам потерпеть бы пару лет.
А там глядишь и дивиденды
Иксы по фишкам голубым
Зелёным ц...
США разрешили транзакции с участием подпавшего под санкции Газпромбанка в области атомной энергетики - Интерфакс Такую лицензию опубликовало OFAC, подразделение Минфина США, отвечающее за правопримене...
Кай Лёд, дебилы. Именно в 20 часов погоду узнали.
18:49
)))
Стратегия от БКС. 💡БКС: индекс Мосбиржи к концу 2025 года может вырасти до 3500 пунктов, а с учетом дивидендов — достигнуть 3800 пунктов, ожидают аналитики БКС. $TMOS
То есть ожидается рост почти н...
Стратегия от БКС. 💡БКС: индекс Мосбиржи к концу 2025 года может вырасти до 3500 пунктов, а с учетом дивидендов — достигнуть 3800 пунктов, ожидают аналитики БКС. $TMOS
То есть ожидается рост почти н...
Ну, где обещанная «экспертами» распродажа и цены по 5000 рубликов? Обосратушки? ))
Илюшкин Данилюшкин, это в сумме с центром и приволжья! не только центра!
ПАО «ЮГК»: растущий золотодобытчик Начиная с момента IPO (ноябрь 2023) акции $UGLD
показали высокую волатильность, не очень то характерную для рынка золота. Компания преподнесла несколько неприятных...
www.influxdata.com/time-series-platform/influxdb/
А насколько они лучше обычных бд. т.е. как там получением данных по каким нить завернутым запросам? :) И в целом удобно ли потом с данными работать?
Да, в целом направление молодое, может не устроить банк (если я правильно расшифровываю LBBW). У нас работает стабильно, нагрузка на железо при подобном режиме работы — минимальна.
Лучше обычных DB скоростью работы, в десятки раз быстрее.
С данными работать удобно — там поддерживается sql
UPD. Это скриншот из встроенного веб-интерфейса, писать данные можно через HTTP API
docs.influxdata.com/influxdb/v1.0/guides/writing_data/
Поддержка sql это хорошо.
Но думаю, что даже в случае внезапного закрытия проекта (пока считаю маловероятным) у вас есть возможность использовать его ещё лет десять. Бинарники на go отличаются тем, что линкуются полностью статически и не содержат никаких внешних зависимостей. Так что если текущий функционал вас полностью устраивает, то можно годами жить без апдейтов (ну и с учётом того, что это закрытая система, а не наружу в интернет).
На данный момент я использую постргри но в таком очень простом его виде, без всяких там примочек.
Но как то у меня не очень удобные структуры данных выходят, все ж приходит асинхронно, поэтому походу хранить чистые не подготовленные данные самое простое решение, но не самое эфективное.
Кстати, а у этой бд есть какая библиотека под C/C++?
Список актуальных API - https://docs.influxdata.com/influxdb/v1.0/tools/api_client_libraries/
В дальнейшем возможно понадобится эти самые данные обрабатывать онлайн.
Хотя, что вы имеете ввиду онлайн?
Сама система будет работь на лету с данными от брокера в обход бд, но возможно понадобится некоторые вещи подкачивать из базы.
— не грузить БД мелкими sql запросами на добавление
— копить данные в некий промежуточный буфер какое то время и потом разом добавить в БД (лично я после мытрств остановился на том, что делаю это 2 раза в сутки и все).
Исходя из этого, пришлось выбирать БД, которая умеет некий буфер сразу помещать в таблицу, без множественных insert запросов. То есть вам нужно добавить к примеру в таблицу 1000 записей и она будет делать не 1000 инсертов, а один какой то свой метод. FIREBIRD например так делать не умеет.
Так умеет делать например:
— sybase
— так умеет делать c# с Entity Framework в связке с Microsoft SQL (тут вообще можно на потоки разделить, если ядер не одно)
— еще какие нибудь БД, с которыми я не столкнулся =)
На примере, если нужно добавить тысяч 200 записей, 200т инсертов может занять минут 8, особенно если много индексов.
Подход через промежуточный буфер решает это секунд за 7-10.
Но тогда второй вопрос, быстро обрабатывать потом данные. Тут уже придется грамотно выстроить индексацию полей и sql запросы на выборку. Вооружайтесь тогда анализаторами и боритесь за секунды =)) При этом надо иметь ввиду, что большое кол-во индексов прямиком влияет на время добавления данных. Приходится все время варьировать в этом вопросе, что выбрать, быстрый insert или быстрый select
В моем случае работа с бд, и работа системы онлайн как бы разделены. Но никто ж не знает как оно будет в будущем )).
А используете чистые данные для записи или делаете какую то предобработку, форматирование?
Но если вы познакомитесь с современными плюшками, там уже даже думать не надо. =)) это я про Entity Framework. Олд скул программирование БД все больше уходит в прошлое =))
Насколько понимаю, твоя задача тривиальна и решается по сути двумя способами(без костылей), Это мелгомягкие технологии или Джава Энтерпрайз(EJB 3.0)- зачем изобретать велоcипеды?
Если брать обычную бд, и сырые данные, то получается что мы имеем много так сказать не нужной информации… тот же тикер ид в каждой из таблиц, но как то же надо их связывать и идентифицировать.
Хотел узнать может есть какой опыт наработанный уже. Что бы не натыкаться на ошибки проектирования :). Но как Андрей сказал имееет смысл смотреть на конкретных задачах.
по поводу .net и явы… первое хорошо но у меня связка c++/qt… ну и иногда питон. А яву я по религиозным причинам не люблю %)