Начну с того, что я нуб

переходите на синтаксис SQL ? , думаю вам MySQL подойдет вполне!

mysql - не встраиваемая

mysql - не встраиваемая

ой сорьки ... не заметил требования!

тогда я за SQLite

?

да и выбор невелик https://www.reddit.com/r/golang/comments/2ldd2l/looking_for_a_embedded_database_for_go/

sqlite - прощай кроскомпиляция

sqlite - прощай кроскомпиляция

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

mysql - не встраиваемая

А было требоаание?

Не знаю. Но просить для бота еще и сервер субд - немного перебор, правда?

Не знаю. Но просить для бота еще и сервер субд - немного перебор, правда?

для бота наверно .... inmemory достаточно будет , тогда действительно односвязный список делать и все!

давно на json перешол в качестве хранилки даже большие данные удобно хранить - индекс прям в path зашит :)

а связку на коленке. бд для ленивых :)

Не знаю. Но просить для бота еще и сервер субд - немного перебор, правда?

Почему? Бот все равно крутится в серверном окружении

лишняя сушность которую ты слабо контролируешь

начиная с миграций

Запихиваешь всё в докер, наворачиваешь docker-compose и никаких проблем

Щас бы в 2017 отказываться от сторонних сервисов потому что ты "их слабо контролируешь"

ну если кажется что это решит проблему - то ок. docker все стерпит

Щас бы в 2017 отказываться от сторонних сервисов потому что ты "их слабо контролируешь"

ну как бы девупс во все поля

Еще докер для статического бинарника

заводы стоят а они электричество на хероту тратят

Вы опухли, как говорили в школе

заводы стоят а они электричество на хероту тратят

Предлагаю пофлеймить об этом в чате биткоина

мое электричество ... чего хочу то и делаю ?

Еще докер для статического бинарника

То что кто-то не готов мириться с реалиями IT индустрии — не проблема IT индустрии) Использовать контейнеры для деплоя — широко используемая практика.

sqlite - прощай кроскомпиляция

У мобильных разработчиков есть хорошая nosql база на с++

То что кто-то не готов мириться с реалиями IT индустрии — не проблема IT индустрии) Использовать контейнеры для деплоя — широко используемая практика.

докер - это один из путей! Не нужно нас толкать ... мы сами придем!

Правильно есть еще lxc

Ребят, я виноват что сразу не написал что мне нужно. Скажу что опыта у меня, кроме как с mongo не было. Мне надо тупо каждому юзеру список длинный, в этом списке данные: "one" "two" "three" и эти данные будут постоянно пополняться. Мне надо проверять этот список на exist, т.е. существует ли нужное мне значение в списке или нет

Ребят, я виноват что сразу не написал что мне нужно. Скажу что опыта у меня, кроме как с mongo не было. Мне надо тупо каждому юзеру список длинный, в этом списке данные: "one" "two" "three" и эти данные будут постоянно пополняться. Мне надо проверять этот список на exist, т.е. существует ли нужное мне значение в списке или нет

да либо хитроумный key и noSQL , либо как никрути 2 ключа поиска ... id_user , name , настраивайся на SQL решение

Ребят, я виноват что сразу не написал что мне нужно. Скажу что опыта у меня, кроме как с mongo не было. Мне надо тупо каждому юзеру список длинный, в этом списке данные: "one" "two" "three" и эти данные будут постоянно пополняться. Мне надо проверять этот список на exist, т.е. существует ли нужное мне значение в списке или нет

"one", "two", "three" это типа столбцы должны быть?

но их количество и набор неизвестно зараннее?

"one", "two", "three" это типа столбцы должны быть?

Это строки

ну их набор постоянный?

Изменчивый

Постоянное пополнение, проверка на существование, редкое удаление

от пользователя к пользователю они повторяются?

Да

вроде набора свойств что-то?

Возможно

users —--------- id properties —------------ id name users_to_properties —---------------------- user_id property_id

наверное как то так

для любой реляционки

USER1: ["value1":true, "value2":false, "value3":true] USER2: ["value2":true, "value3":false] Что-то такое меня бы устроило

Не знаю. Но просить для бота еще и сервер субд - немного перебор, правда?

А есть вариаенты?

USER1: ["value1":true, "value2":false, "value3":true] USER2: ["value2":true, "value3":false] Что-то такое меня бы устроило

ну так в любой бд можно хранить, и в той же mongo и в реляционке многие ко многим

Господа, а что вы сейчас изобретаете?

а тут по истории можно посмотреть

или вам персонально рассказать?

USER1: ["value1":true, "value2":false, "value3":true] USER2: ["value2":true, "value3":false] Что-то такое меня бы устроило

Попробуй boltdb

Попробуй boltdb

Почитал, попробую, спасибо! Не пойдет, так выберу mongo

На самом деле - база тут вовсе не нужна

или вам персонально рассказать?

Рассказать чем не подходит mysql какой нибудь для сервиса на 100 обращений в секунду макс.

Данных мало

А в реальности 1 обращение в 100 секунд

Запросы редко

Держите все в памяти, и дампите на диск при каждом изменении

При старте - всасывайте

Держите все в памяти, и дампите на диск при каждом изменении

Тоже вариант, только если это дело упадет, данные могут потеряться

Как будто они с базой не могут потеряться

если запросы редко зачем память замусоривать? из 1к юзеров 10 активных а данные держим для всех

И сколько тех данных?

Ну, давайте, предположите

это к ванге вопрос )

Не совсем

ERROR: S client not available

Топикстартер же написал, чего хочет

Кто не писал чатбота на Го в этом чате - не поднимите руки!

https://imgflip.com/i/1ygkdk

Топикстартер же написал, чего хочет

и что же он написал?

USER1: ["value1":true, "value2":false, "value3":true] USER2: ["value2":true, "value3":false] Что-то такое меня бы устроило

Вот это

Тоже вариант, только если это дело упадет, данные могут потеряться

я бы тоже решал inmemory ... когда бы дорос до больших обьемов ... перешел на key/value (где key формировал бы как строковую величину "id/name" ) а потом бы плюнул на все и ушел на MySQL

Вот это

ну то есть хранить словарный запас юзеров в чате, да? )

Какие такие объемы у бота?!

это от бота зависит

О, да, конечно

От бота

ну ок, какие данные например у антиспам (нормального) бота?

ну или у бота собирающего статистику?

Скажите мне вы

Сколько там в байтах?

ну вы ж тут вроде как знаете все про данные ботов?

USER1: ["value1":true, "value2":false, "value3":true] USER2: ["value2":true, "value3":false] Что-то такое меня бы устроило

Вот это можно в битовой арифетике хранить вобще по хардкору. Таблица состояний. Вопрос есть схема или нет.

вот вы и скажите, сколько там в байтах и зачем это хранить в памяти

ну вы ж тут вроде как знаете все про данные ботов?

Не надо увиливать. Сделайте утверждение.

я сделал, сейчас найду его

это к ванге вопрос )

вот оно

вот вы и скажите, сколько там в байтах и зачем это хранить в памяти

нормальные даже большие размеры в памяти очень хорошо живут! Границы БД и памяти очень размыты

живут они где угодно хорошо, только зачем хранить в памяти то что там не нужно?

Не изобретайте велосипеды: это классический KV storage. Есть Redis, он умеет в персистентрость через диск

Редис, кстати, говно

Не изобретайте велосипеды: это классический KV storage. Есть Redis, он умеет в персистентрость через диск

с опциональной потерей данных, да

живут они где угодно хорошо, только зачем хранить в памяти то что там не нужно?

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

Редис, кстати, говно

+

Редис, кстати, говно

Почему?

Редис, кстати, говно

голанг кстати тоже

Почему?

по всей улице