естественно если мы не говорим о 5$ сервере на DO

Меня удивляют люди. Запускают хелловород и сразу ждут 1 Тб данных и хайлоад

как быстро система индексирует данные?

вот эти 100 гигов?

ну слушай я не помню цифр но проблем у нас нет вроде

сегодня начнет заливать данные , что дальше будет?

в соседнем банке MSSQL с базой в 280 Гб тоже живет ок

Если база статичная, то что тут говорить

если банк, то там очередь есть к базе

всех никогда не пускали

там сервер приложений перед БД и у него пулл коннектов. очереди нет т.к. транзакции

я вот бывший работник сбера

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

что такое в реале минимум 10 000 клиентов, эти клиенты тетки в отделениях

ну я рад за тебя. лет 15 назад я работал с 1С и там перепроведение документо занимало всю ночь) но это скорее говно арх-ра чем проблемы БД

у меня есть в перконе база на > 300гб, и все работет баз проблем, находится под активнмы чтением/записью. на не самом мощном сервере (правда с ssd)

объем это один момент, важнее тут кол-во клиентов

один пишет, другой читает

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

но тут не в базе дело тогда)

И потом если ты топишь за MongoDB то почему она ? Есть аналогичная CouchDB, Couchbase, Aerospike, etc

ну и есть Redis

вот в чем отличие Redis vs Mongo?

один пишет, другой читает

дак это решаемая проблема. на уровне арх-ры системы и уровнем изоляции транзакций. и да read-commited не всегда подходит

в момент записи идет блокировка

вот в чем отличие Redis vs Mongo?

ты тут тесты устраиваешь ? K/V хранилище с БД сравниваешь ?

так монго же K/V

монго это документо-ориентированная БД. хранит JSON в виде BSON.

аллилуя

так что дает Json?

как быстро объект получим на бэк то?

если так далеко копать то любая БД работает с plain file

какой то тут странный спор ниочем

ну не любая

есть еще in-memory

есть моменты где скл четко, а есть где скл просто гнать надо

есть еще in-memory

любая хорошая in-memory умеет синкатся на disc. как тот же redis

хех

dict в python тоже вполне себе база данных )

и синкаться умеет через pickle ))))

зачем все эти монги-шмонги...

ну в принципе да

в Erlang есть ETS тоже БД

угу... и std::vector в cpp

в монго есть шардинг, а значит вычисления можно разнести по серверам

в монго есть шардинг, а значит вычисления можно разнести по серверам

да шутим мы, что ты...

сорян

в монго есть шардинг, а значит вычисления можно разнести по серверам

Какие вычисления разносить по серверам? 15 клиентов на 2 сервера за 5 баксов?

у всех же хайлоад и петабайты данных )))

Расскажете про отдельные случаи? В каких именно монго хороша?

Я далеко не эксперт в этом. Но если вы правильно спроектировали реляционную БД и при каждом запросе у вас миллион join'ов, то лучше взять NoSQL БД. Лично я вижу это так, но я далеко не эксперт

Я далеко не эксперт в этом. Но если вы правильно спроектировали реляционную БД и при каждом запросе у вас миллион join'ов, то лучше взять NoSQL БД. Лично я вижу это так, но я далеко не эксперт

ну так проектировать надо не по книжке, а под реальную задачу

В постгресе тоже есть жсон если так прям хочется. Индексируемый.

до шардинга еще надо дорасти дорасти. Какие еще аргументы за монго?

вот я тоже хотел услышать

а нет их

в ботах вообще нету такой пропускной способности чтобы шардинг понадобился. Тут хоть у одного ботовода он есть?

Это уже не говоря о том что шардинг это более высокоуровневое понятие чем sql/nosql и опять же в постгресе его можно сделать, разве что будет более коряво

Если вам нравится постгри то флаг в руки

есть момент, что делать, если структура таблиц поменялась?

дабавили поля?

Написать миграцию и применить ее

так что каждый день ?

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

вчера добавили поля, сеня еще , а завтра удалим

будет писать альтер тейбл, а далее на обработке

поля нет, опппа

такие грязные данные можно писать в JSONB пока схема не устаканется. Мы так и делаем. Зато получаем честные транзакции

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

в монго таких проблем нет

если делать все на 1 машине, то не спорю проблем нет

если парк машин, то обовление на каждой тот еще фокус

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

я не представляю кейс, в котором сегодня поле есть а завтра нет. хрень полная

С ростом объема легаси подлерживать старые форматы данных становится нереально

лан давай те,

как вы пользователя достаете из базы данных?

как добавляете?

раз уже тема телега девелоперлс

Шта значит как? Sql операторами конечно же

давай те код

вот вам гошки код

type User struct { Userid int //ID пользователя Username string // Contact's username Firstname string // Contact's first name. Lastname string // Optional. Contact's last name. Timestamp time.Time // когда появился пользователь } user := User{} err = collectionUsers.Find(bson.M{"userid": message.Sender.ID}).One(&user) if err != nil { fmt.Println("-> не найден") err1 := collectionUsers.Insert(&User{message.Sender.ID, message.Sender.Username, message.Sender.FirstName, message.Sender.LastName, time.Now()}) if err1 != nil { fmt.Println("не смогли сохранить пользователя") fmt.Println(err1) } } else { fmt.Println("->есть") }

тут нет скл , база монго

могу любое поле в User вставить, оно будет совместимо

Шта значит как? Sql операторами конечно же

This

because we can ! (c)

могу любое поле в User вставить, оно будет совместимо

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

Или удалять по ошибке

ога выше еще скажите что drop database спасает сильно

удаляют / добавляют поля, а потом в коде 1000 проверок, есть ли такое поле или нет

зачем делать проверки?

там будет пусто

ну получай свои нулы.

"есть ли такое поле или нет" это скл , оператор же *

вот такое SELECT * FROM mytable меня отучили делать уже давно

потому что sql проблемы с этим

зачем делать проверки?

Чтобы не положить случайно в скалярное поле коллекцию или строку туда где должно быть число.

Чтобы не положить случайно в скалярное поле коллекцию или строку туда где должно быть число.

сэтим в монго нет проблем