Какую базу данных выбрать для Телеграмм бота

Сегодня поговорим о базе данных, рассмотрим, что это такое, как пользоваться, нужна ли она в вашем боте, и какую лучше выбрать под какую задачу.

Что это вообще такое база данных

Если подходить буквоедски, то база данных (БД) — это набор данных, собранных в одном месте. Неожиданно, правда?) Например, под базой данных можно понимать список контактов в телефоне, воспоминания в голове и всякие подобные вещи.

Система управления базами данных (СУБД) – это набор программ и средств для работы с данными – сохранение новых данных, изменение старых, выбор данных по определенным критериями и т.п.

Но мы в данной статье не будем делать различий, и как все обычные люди, будем называть базой данных то одно, то другое, и во всём разберемся.

Применение

Как и любая другая программа, база данных решает определенную проблему, в данном случае проблему промежуточного хранения данных.

Казалось бы, можно было бы написать и запустить программу, она бы отслеживала курсы, покупала, продавала, и всё было бы прекрасно. И для небольших программ это действительно работает, но всё меняется, когда программа работает больше одного часа.

#03 Подключаем базу данных (Разработка Telegram бота на NodeJS)

Такую программу иногда приходится перезапускать, иногда вместе с компьютером, иногда она ломается из-за сбоев, иногда оказывается, что в программе есть баг, и нужно его исправить и продолжить работу алгоритма.

Вот именно в такие минуты и понимаешь, что программа выставила ордер на бирже, получила его ID из ответа биржи, отслеживает его, НО НИКУДА НЕ ЗАПИСАЛА. И вот теперь, когда программу нужно перезапустить, она его забудет (((. И начнёт все сначала, и придется руками лезть на биржу, что-то там менять, и вообще вечер обещал пройти более интересным способом.

Нужно садиться и всё переделывать. Но это не всегда.

Какие данные можно НЕ хранить?

Хочу, впрочем, заметить, что не всегда нужно усложнять мир вокруг себя, и есть масса сценариев, где ничего никуда записывать не нужно.

Например, скрипты, которые предназначены для выполнения разовой задачи (например, залезть на биржу, взять свечи по всем парам, провести анализ и вывести список подходящих), вообще, наверное, нет смысла делать длиннее 100 строк кода. Настроечные параметры можно вынести в конфиг-файл или в аргументы командной строки, промежуточные данные хранить в словарях и массивах, которые эта программа и создает.

В примере выше, где мы отслеживали только ID ордера, мы могли бы его записывать в файл, и при запуске файла читать из него – если запись есть, то и ордер есть, нет записи – начать алгоритм с нуля и т.п.

В некоторых случаях, например, когда мы торгуем только ботом, можно использовать биржу в качестве БД – например, на старте получать список выставленных ордеров через запрос к API, и прорабатывать их.

Настоящая потребность в использовании БД возникает, когда нужно хранить большие объемы данных, и иметь возможность быстрого к ним доступа.

Практическое применение

БД длительного хранения

В случае простого бота мы гипотетически записывали в файл ID ордера (и может быть дополнительную информацию о цене, объеме и т.п.), но что, если мы собираемся торговать сразу по 60 парам? Заведем 60 файлов по одному на каждую пару или будем жонглировать записями в текстовом файле?

Как сделать систему регистрации для Telegram бота

А если мы решим добавить к каждому ордеру еще и время создания, нужно будет менять формат файла, функции добавления, изменения и удаления. А потом мы решим, что было бы неплохо иметь возможность строить несложные отчеты по прибыли, кол-ву ордеров в час/день/месяц в разбивке по паре, и забудем файлы как страшный сон.

Итак, мы решим использовать базу.

Я назвал этот подраздел «БД длительного применения», т.к. хотел в нём обсудить базы данных, подходящие для постоянной рутинной работы. Такие базы данных организовывают данные внутри себя в виде таблиц (как в экселе, с заголовками), и позволяют из одних таблиц ссылаться на другие (такие базы данных называют реляционными, от английского слова relation – отношение).

Примеры таких баз – в порядке увеличения производительности, но и сложности работы с ними:

Немного пробежимся по ним, без погружения в детали, при необходимости напишем отдельные статьи.

SQLite

Эта БД имеет свою нишу на рынке, т.к. является встраиваемой (единственная в моём списке). Это значит, что для работы с базой не требуется скачивать дополнительных программ, устанавливать и т.п.

Вам достаточно написать код вашего бота, добавить туда модули для работы с SQLite, и ваш код создаст файл базы данных в папке с ботом (или в другом месте, или вообще в оперативной памяти), и вы сможете работать с этой БД, и выполнять стандартные SQL команды (SELECT, INSERT и т.п.).

Фишка в том, что потом вы дадите код товарищу, он запустит его в часах, компьютере с другой операционной системой, на орбитальной станции, и там не придется ничего дополнительно устанавливать, ваш код просто начнет работу.

Но, разумеется, у неё есть и слабые стороны. Во первых, блокировка – когда вы вносите изменения в БД, вся база блокируется до фиксации изменений. Если вы работаете в одном потоке программы, или редко что то записываете, то это в общем то и не проблема.

Но для нагруженного проекта лучше брать что-то помощнее.

MySQL/MariaDB

БД с непростой судьбой. Когда-то разработчики отказались продаваться Oracle, и планировали самим вырасти и выкупить Oracle. Но в итоге так и не выстрелили, их купили, для этой базы был создан свободный форк MariaDB, и теперь две ветки развиваются параллельно.

В проекте средней руки, в MVP и домашних проектах, впрочем, данная БД сможет покрыть около 100% потребностей, если не желать слишком многого.

Из недостатков работы с этой БД я бы выделил вечные проблемы с кодировками, которые задаются на уровне БД, таблицы и колонки таблицы и могут различаться во всех трех случаях, не говоря о сессии. Индексы, когда по ним осуществляется поиск, блокируют таблицу, как ни странно, и документация по работе с БД организована не слишком удобно (зато всё отлично гуглится на стэкфверфлоу).

При установке под Windows ставится много лишнего, интерфейс неочевиден и неудобен (под линуксом всё прекрасно в консоли), но мне кажется, под Windows лучше вообще не затачиваться.

Есть хорошая поддержка различных операционных систем, работать в консоли довольно удобно.

Для каких-то совсем ненагруженных проектов я бы, возможно, выбрал именно эту базу данных.

PostgreSQL

Наиболее продвинутая БД, едва ли не самая мощная из бесплатных. Есть поддержка разных ОС, встроенный язык программирования для хранимых процедур, возможность использовать скриптовые языки, поддержка хранения различных типов данных (например, JSON, IP, массивы, диапазоны, геометрические данные и т.п.).

Я знаю организации, которые отказались от использования платного MSSQL в пользу PostgreSQL для работы 1С.

Думаю, под большой серьезный проект, например многопользовательский сервис, я бы выбрал эту базу в качестве основного хранилища данных, за счет производительности и возможностей масштабирования.

Oracle

Проприетарная БД от одноименной компании. В основном заточена под работы с UNIX системами, а также является платной. Впрочем, у неё есть бесплатные урезанные решения, которые позволяют работать и разрабатывать программы с этой БД, а так же их политика в целом не гнобить каждого, кто поставил их расширенную версию без лицензии. Но, конечно, это не значит, что можно пиратить.

Сама по себе база весьма шустрая при правильной настройке, а также эффективно утилизирует ресурсы сервера. Есть IDE довольно высокого качества, и множество возможностей. Правда, для их освоения могут потребоваться годы, курсы и куча литературы. И да, без английского особо делать там нечего.

MSSQL

БД от Microsoft. Заточена под работу под Windows, имеет отличную среду разработки, удобный интерфейс, очень легкий порог входа. Правда, она, как и Oracle, платная с бесплатными урезанными вариациями.

При установке можно сразу установить сервис отчетности, где делать отчеты в разных масштабах.

Эти две последние базы – Enterprise. У них много возможностей, но они не рассчитаны на работу с небольшой нагрузкой, они мощные и крутые, но такие обычно устанавливают на предприятиях.

Более того, на тех же предприятиях их ставят зачастую не потому, что они лучше того же PostgreSQL, а потому лучше решают сторонние задачи бизнеса:

1. Под MSSQL проще найти разработчиков, Microsoft расстарался, везде поставляя свою ОС и свою БД, а также интегрировал сервисы в общую инфраструктуру – например, можно рулить правами доступа в БД на уровне сисадмина в Active Directory, с другими базами придется повозиться.
2. Сервис и поддержка – крупная контора, банк или национальная ЖД компания скорее заключит договор с Microsoft, чем с волосатиками, которые локально поддерживают другую БД. В случае сбоя уровень компенсаций будет соответствующим.

Мой посыл в том, что база MSSQL на самом деле крутая, но для ботов её бесплатная версия не даст нужной производительности, а крутая расширенная – платная и дорого стоит.

Но есть еще и другие задачи, которые базы данных могли бы решить, и об этом отдельный раздел.

БД быстрого доступа

Есть задачи, которые требуют быстрого доступа и обработки данных. Например, получать данные из сокетов по всем парам, хранить их на случай сбоя и иметь возможность быстро строить по ним какие-то модели.

Или, например, собирать свечи по всем парам, агрегировать их на лету.

Есть отдельный класс баз данных, которые из коробки позволяют обрабатывать сотни тысяч операций в секунду, но это за счет того, что они в основном живут в оперативной памяти и лишь изредка скидывают информацию на жесткий диск (и то не все это делают).

К таким базам можно отнести Redis, MongoDB, Couchbase server и т.п.

Вот, например, результат работы Redis на макбуке

$ redis-benchmark -n 1000000 -t set,get -P 16 -q SET: 403063.28 requests per second GET: 508388.41 requests per second

Эти базы данных не только живут в оперативной памяти, но еще и используют другую систему хранения – например, там нет таблиц, как в реляционных БД, но есть словари, множества, массивы и т.п.

Такие базы хорошо использовать для оперативной работы, как отдельно так и в дополнение к классической реляционной. Тем не менее, часть из них умеет сохранять данные в процессе работы в фоновом режиме, так что если будете работать в Redis и придется перезагрузиться, то, скорее всего, данные не потеряете. Но цена за это – медленный старт БД, которая с диска будет считывать всё обратно в память при запуске.

Заключение

Надеюсь, такая систематизация данных пригодится вам в том или ином виде, если возникнут дополнительные вопросы, буду рад на них ответить.

Не забудьте рассказать друзьям об этой статье.
Чтобы поддержать ресурс Bablofil достаточно просто поделиться с друзьями этой статьей в социальных сетях. Каждый репост — это самая высокая оценка качества материала. Спасибо, что читаете этот блог.

Источник: bablofil.ru

Какую бд выбрать для телеграм бота?

Здраствуйте! Я создаю телеграм бота, мне нужна база данных для телеграм бота. И вот у меня ступор какую бд выбрать? В бд мне нужно хранить: название рецепта , сам рецепт , ингридиенты. И также у меня возник вопрос большенство легких бд нужно создавать кодом?

Ответы (2 шт):

Давайте сначала разъясним пару моментов:

• СУБД (система управления базами данных) — в этом случае мы имеем ввиду систему, которая занимается хранением данных и дает интерфейс для взаимодействия с ними (примеры: SQLite, MySQL, PostgreSQL). Они бывают серверные и встраиваемые. Реляционными и нереляционными. Почитайте статью про сравнение СУБД, упомянутых выше в качестве примера https://tproger.ru/translations/sqlite-mysql-postgresql-comparison/. Внутри статьи найдется множество ссылок для более подробного изучения. Начните с реляционных баз.
• ORM (object relational mapping) — это прикладная штука, совершенно опциональная для СУБД, позвляющая писать в программе классы, экземпляры которого, выражаясь упрощенно, будут сохраняться в базе данных (популярный пример: SQLAlchemy). Скорее всего это именно то, что имелось ввиду «создавать кодом». Создаются базы данных не кодом, а специальными запросами, например, на языке SQL. Обязанность ORM переводить классы в структуры будущей БД и за программиста генерировать эти запросы.

В общем, если нужна серверная база данных для большого продакшена, то наверняка подойдет MySQL. Вариантом чуть попроще будет — SQLite. Эта СУБД хранит данные в специальном бинарном файле и позволяет не заморачиваться с установкой сервера.

Если коротко — попробуйте для бота сначала SQLite.

Но раз вы сильно начинающий, давайте сначала попробую обьяснить некоторые термины на пальцах.

БД — представьте, что это некий блокнот, тетрадь, книга, что-то такое. Чтобы работать с этим блокнотом, есть ряд инструментов, котрые позволяют создавать данные там (карандаш), хранить большое количество (шкаф), упорядочить для поиска нужного (картотека) и т.п. То есть можно, как вы выразились, создавать БД (блокнот) кодом (руками), можно как то автоматизировать (печатать на принтере) и т.п.

В программировании все очень схоже, но добавляется. наверное назовем это уровнем абстракции. Есть встраиваемые БД (embedded), есть СУБД, в свою очередь они распределяются на реляционные (обычно подразумевают SQL) и нереляционные (NoSQL), которые в свою очередь уже часто разделяют на универсальные и узкоспециализированные.

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

Соответственно, если БД только для бота, берите встраиваемую БД, тут практически стандартом все советуют SQLite (хотя есть и другие варианты). Это хорошо оптимизированная и отлаженная библиотека, которая работает внутри вашего приложения, хранит данные в одном файле и работает действительно быстро, даже с определенным уровнем защиты от сбоев. Даже больше того, SQLite предоставляет некоторый режим работы, когда к этой БД (файлу) может иметь и другой процесс, не только чтобы прочитать оттуда данные, но даже записать или изменить, одновременно с вашим приложением бота. В общем интересная штука, она сейчас используется повсеместно, в любом телефоне, во многих программах (музыкальные плееры, почтовые программы и т.п.), даже в браузере есть некое ее подобие (WebSQL). Конечно же, есть не только SQLite (например в будущем можно посмотреть на LevelDB, PouchDB, есть множество различных реализаций на разных языках программирования других концепций).

Другой вариант — если вам нужно некоторое централизованное хранилище с одновременным полноценным доступом нескольких разных приложений (несколько ботов, сайт, мобильное приложение и т.п.). Тогда в этом случае либо пишут поверх БД API для обмена данными (чаще просто REST поверх HTTP), либо берут СУБД. Один из самых распространненых вариантов это MySQL или MongoDB.

Если хочется чего-то серьезного, то можно попробовать PostgreSQL, если чего-то попроще, не знаю, Redis, CouchDB. Если этот вариант вам нужен, попробуйте какие-то начального уровня программки написать под работу с данными в MySQL или в MongoDB и поймете, что именно из этого вам подойдет. Просто почитайте пару статей типа Getting Started, How to и перепишите оттуда код, запустите и посмотрите результат.

Отличаются они подходом к хранению данные — SQL варианты это таблицы в БД, с заранее определеной структурой (названиями столбцов и типом хранения в них данных), с четким языком запросов на создание, изменение, удаление и поиск данных (SQL это и есть язык запросов). Это SQLite, MySQL, PostgreSQL. NoSQL — это хранение данных с другим подходом. Например, документами целиком, как в MongoDB, PouchDB/CouchDB.

Или списком ключ-значение, как в LevelDB, Redis. В вашем браузере тоже есть такие БД, IndexedDB, LocalStorage, SessionStorage, Cookies, все это примеры NoSQL решений. Так что это не что-то «гиковское», но да, со своим подходом, кому то нравится, кому то нет.

У таких БД есть либо свой язык запросов, обычно на базе JSON/JavaScript (поэтому например MongoDB очень популярен у тех, кто пишет на NodeJS), либо совсем простейший GET/SET с вариациями.

Следует еще уточнить, что сейчас уже все не так однозначно, потому что, к примеру в последних версиях MySQL, а в PostgreSQL уже довольно давно, можно хранить в полях документы в JSON формате и даже работать полноценно с полями оттуда, индексировать, искать. Равно как и в NoSQL СУБД есть некое подобие QL-языков запросов, похожих на SQL.

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

Хранит и хранит. Это одновременно и удобно и не очень хорошо. Удобно тем, кому заходит ООП, работаешь с обьектами данных и не задумываешься о том, как это хранится. Не очень хорошо тем, что разработчик перестает понимать, как на самом деле происходит работа с данными в используемой СУБД, зачастую теряет на этом определенную долю производительности.

Есть еще колоночные БД, где похоже как в SQL, но данных упорядочиваются не по строкам, а по столбцам, но это точно не для вашей задачи.

Как то так. Написал я вам много, надеюсь не взорвал мозги, но постарался сжато.

Источник: husl.ru

Какую базу данных использовать для телеграмм-бота?

Нужно хранилище данных для телеграмм-бота (БД для текстовых сообщений ). Подскажите пожалуйста, какую базу данных лучше использовать.
Будет круто, если кроме ответа на вопрос, оставите учебный материал по этой БД.

• Вопрос задан более трёх лет назад
• 2384 просмотра

Комментировать
Решения вопроса 0
Ответы на вопрос 2
Ответ написан более трёх лет назад
Нравится 2 1 комментарий

С sqllite есть момент:

.
Перед началом исполнения транзакции записи весь файл, хранящий базу данных, блокируется.
Запись в базу можно осуществить только в том случае, если никаких других запросов в данный момент не обслуживается в противном случае попытка записи оканчивается неудачей, и в программу возвращается код ошибки. Другим вариантом развития событий является автоматическое повторение попыток записи в течение заданного интервала времени.
.

Т.е. читать из БД можно многопоточно, а вот запись в несколько потоков вызовет сложности.
Если конечно несколько инстансов бота могут обращаться в одной sqllite.

Программист, энтузиаст

Всё зависит от того, какие задачи будут у вашего бота, какая будет у него архитектура, насколько сложные модели данных, собираетесь ли использовать ORM и какой именно.
А может быть вам реляционная структура БД и вовсе не нужна и больше подойдёт NoSQL база данных.
там их великое множество с разными возможностями и ограничениями от простых хранилищ ключ-значение, до развесистых и навороченных.

Я бы порекомендовал MongoDB.
Для питона есть огромное количество примеров и тьюториалов типа такого. Куда уж понятнее.

С Монгой вы избежите необходимости возиться со схемой БД, можно избежать специфического процесса инициализации базы, создания ее структуры.
Если данные, которыми будет оперировать ваш бот разнообразны, то неплохая идея написать модели в виде обычных питоновских классов, сделать методы сериализации (сохранения) в БД и десериалиации (загрузки) и забыть о базе как о какой-то отдельной сущности. Можно сконцентрироваться на логике работы.

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

P.S.
Прошу прощения за капитанские ссылки в тексте, но каков вопрос, таков и ответ.

P.P.S.
Должен признать, что я довольно предвзят в пользу монги. Скорее всего вам подойдёт всё что угодно.
Меньше всего потребует настройки и знания, видимо, sqlite. Это embedded база данных, она заточена для простого использования. Однако если вам вдруг понадобится запускать несколько инстансов вашего бота, которые будут работать с одной БД, то посмотрите всё же в сторону MongoDB или Postgres. Mysql стал сдавать позиции и нет особых причин не использовать postgres, если вам нужна именно реляционная БД.

Источник: qna.habr.com