да

с ssh

Всем привет, тут можно задавать нубские вопросы? На локалхост работает, пробую запустить на вдс, голанг в консоли все нормально, но с айпи нельзя зайти, пробовал порты ставить 80 и 7777, хостинг 1gb.ru, порты открыты, по тому же айпи открывается панель хостера на php на порту 1234

Может оно только localhost у тебя слушает ?

Действительно, код с интернета, http пример helloworld работает, спасибо большое

Помогите с выбором хранилища для данных http://telegra.ph/Est-li-takaya-nosql-02-26 , postgres как вариант понятен, оно и сейчас там, но надоели кучи джойнов, хочется какой то документной базы.

Удивительно

Надоели джойны - сделай одну таблицу, в ней два столбца

Первый - уникальный индекс

Во второй свали сериализованным все остальное

Да хоть jsonом

Так, лады. Свалил.

И будет ТОЧНО как в nosql

where по приjoin таблице будет?

Конечно! Полным перебором

Ну да, а выбирать то как потом, мне потмо запросы нужны пот по той , json части выборки

тогда перфомансу конец

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

А почему вы решили, что в nosql иначе?

в nosql будет тоже самое

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

Постгрес

я бы делал две таблицы

Кассандра

и смотрел откуда фильтровать будет дешевле

Аэроспайк

я наслышан есть какие то aggregation frameworks и всякие там прочие вторичные индексы

кассандра не поможет

Надоели джойны - сделай одну таблицу, в ней два столбца

не, ну jsonb манит. но я такой даже постгрес поставил, что отдельная боль, а поотом понял, что немсмог подобрать щадачу под эту красоту

С монгой не работал

Но

jsonb тоже не панацея

даже с индексами

Nosql - это именно таблица из двух столбцов плюс вторичные индексы

Наслаждайтесь

ну в mongo можно будет сделать на встроенном aggregate framework map-reduce

только это перебор будет

Именно

меня только одно интересует нафига такие схемы данных выбираете чтобы потом боль испытывать?

Ладно, это понятно. Я понимаю что key-value это таблица с двумя полями. Просто то что люди как то это юзают, заставляет меня думать что они как то умеют эти вторичные индексы строить так что б эфективно внутрь лазить.

Ведь мой вопрос он про вторичный индекс, сможет ли он индексировать как бы массив внутри этого документа.

postgresql сможет

но до определенных пределов

советую посмотреть в jsonb секцию и индексы

Спасибо. Посмотрю.

меня только одно интересует нафига такие схемы данных выбираете чтобы потом боль испытывать?

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

сделать тестовую таблицы и погонять explain

Помогите с выбором хранилища для данных http://telegra.ph/Est-li-takaya-nosql-02-26 , postgres как вариант понятен, оно и сейчас там, но надоели кучи джойнов, хочется какой то документной базы.

Postgresql +jsonb Или mongodb Первое надёжнее, второе - проще

И быстрее на запись

mongodb тормоз будет

он только как write-only хорошо работает

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

тогда да

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

Слушайте, а просто колонку индекса добавлять не?

А как, там же массив внутри то

если данных мало до 1М то постгресс это очень быстро даже

https://www.postgresql.org/docs/9.6/static/datatype-json.html

Ладно, это понятно. Я понимаю что key-value это таблица с двумя полями. Просто то что люди как то это юзают, заставляет меня думать что они как то умеют эти вторичные индексы строить так что б эфективно внутрь лазить.

В этом смысле РСУБД всегда будет эффективнее

Т.е там условно, список статусов , какая колонка то, это ж уже таблица и джойн опять.

если у тебя строк до 1М сделай джоин уже

это будет быстро

Это ты как хочешь

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

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

приведу пример с монгой

Если не затруднит

есть большой поток данных, нужно с него снять метаданные какие-либо для последующего анализа и записать

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

https://docs.mongodb.com/manual/indexes/

mongo отлично подходит с шардированием для такого wirte-only процесса

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

делать это на SQL можно, но транзакционность убьет нахрен производительность

Сложнее

Но - да

Примитивная структура позволяет лопатить данные быстрее

именно

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

Везде по-разному, в монге тупо указываешь поля, по которым строить индексы

И не апдейтишь их потом, так?

https://docs.mongodb.com/manual/indexes/

Compound Multikey Indexes похоже мой вариант для массива внутри документа.

В кассандре - не апдейтишь

И не апдейтишь их потом, так?

Ага Дропаешь и делаешь новый

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

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

Да нет же

Да нет же

А можете так, однимм словом, вот я там запросы написал в посте-вопросе, сможет монга такие индексы построить и выбирать без перебора?

А можете так, однимм словом, вот я там запросы написал в посте-вопросе, сможет монга такие индексы построить и выбирать без перебора?

Заранее скажешь монге, какие индексы нужны, потом пихаешь данные. Она строит индексы

Знаете для чего удобна монга? Хуяк хуяк и прототип

Прям ваще

Т.е. ей лезть внутрь документа и выбирать там по паре полей внутри массива, это возможно?

Index Arrays with Embedded Documents это оно?

https://docs.mongodb.com/manual/core/index-multikey/

Спасибо.

А вот "уметь такие" индексы это в целом стандарт для nosql или тока монга

Я везде видел, где вообще есть вторичные

Понятно, спасибо

делать это на SQL можно, но транзакционность убьет нахрен производительность

в постресе можно сделать fsync = off, но получим ту же монгу по надежности

А можете так, однимм словом, вот я там запросы написал в посте-вопросе, сможет монга такие индексы построить и выбирать без перебора?

Конечно сможет. Преимущество mongo, в данном случае, в том что она может работать с вложенными документами(вам нужен будет $push), в отличии от jsonb(postgres)(на сколько я знаю).

проводили простенькие тесты в монге, иногда тупило на поиске по индексу аж 500-800мс... может конечно с диском еще были проблемы :D коллекция была всего 30кк записей

А вот godep надо использовать, или что то уже на замену пришло?

мне глайд нравится, каким бы он ни был глючным