Egor
думаю что есть смысл накинуть нагрузку по сжатию-разжатию на клиент и на сервер, но при этом максимально ускорить веб обмен данынми, ибо устройства щас вполне пристойные всюду, а вот интернет часто говно
Egor
а если говорить о других странах, так в рашке интернет один из самых быстрых
Egor
в grpc оно вообще из коробки как бы
Egor
тип http/2.0
Egor
согласен, но это corner edges - кому это правда нужно, остальные просто хвостом цепляются лишь бы микросекунды были)
соглашусь с тем что порой лучше оптимизировать сами сервисы, уменьшая количество лишних операций и флуд в данных, чем тупо жать данные
Egor
с другой стороны лучше делать и то и то, если это не сильно замедлит (удорожит) разработку:)
Amir
я за корректность)
Ярослав
Как правильнее будет?
block: {
nick: Boolean,
bonus: Boolean,
pari: Boolean,
tir: Boolean,
family: Boolean,
gun: Boolean,
prof: Boolean,
glove: Boolean,
job: Boolean,
kit: Boolean
}
или
block: Object
Ярослав
const User = new mongo.Schema({
block: {
nick: Boolean,
bonus: Boolean,
pari: Boolean,
tir: Boolean,
family: Boolean,
gun: Boolean,
prof: Boolean,
glove: Boolean,
job: Boolean,
kit: Boolean
}
});
yopp
хранить временные отметки цифрами почти всегда архитектурная ошибка
yopp
никакой оптимизации тут нет и быть не может, это даже не на спичках экономия
yopp
это даст сложности с конвертацией даты, нужен свой обработчик в приложение
никакой сложности не будет, потому что в любом случае у вас документы хранятся в BSON, а сериализатор чтоб удовлетворять спецификации просто обязан кастить datetime в подходящее представление.
Dmitriy
я имел в виду логическую сложность внутри приложения)
yopp
вы сейчас мышей оптимизируете
Dmitriy
представьте на проект придет новый программист, который должен будет разобрать что за хрень тут наделана
Dmitriy
вместо того чтобы использовать стандартные типы
yopp
да, именно так оно и будет если вы начнёте вместо даты использовать числа
yopp
и вы получаеет вместо explicit семантики, implicit семантику
yopp
в каком часовом поясе хранится отметка? с каким разрешением? какая точка отсчёта и ещё сотни других проблем связанных с сериализацией времени
yopp
и всё это при наличии двух нативных типов отметок timestamp и utc date
yopp
отдельный адочек будет когда кому-то захочется сделать агрегацию по суткам например
Й
Чет не совсем ясно какой из этого вывод?
В каком формате НУЖНО хранить дату?
yopp
в "\x09" aka UTC datetime
yopp
http://bsonspec.org/spec.html
yopp
во что ваш драйвер кастит этот тип аттрибута смотрите в документации к вашему драйверу
Й
Спасибо большое!
Даниил (Onix)
Уважаемые, поскаджите.
Я сделал новую базу. В ней создал коллекцию. Правда ли что команда show dbs не покажет мне эту базу, пока я не заполню ее хотя бы одной записью?
Даниил (Onix)
(у меня сейчас так и я не понимаю почему)
Й
Нет. Не правда
Й
Хотя у меня монга древнющая как говно мамонта
Даниил (Onix)
Ребята, скажите, можно ли как-то это обойти?
npm WARN mongoskin@2.0.3 requires a peer of mongodb@~2.0 but none is installed. You must install peer dependencies yourself.
у меня Монга более новая... а тут курс прохожу, там монк и монгоскин
Даниил (Onix)
Спаибо что не отвечали. Я был упорен и нашел решение (решенние - установить монк посвежее).
Alexander
А можно ли что-то поставить на сервера, чтобы управлять монгой по HTTP?
Alexander
Остановка, перезапуск, initial sync
Fire Walker
А можно ли что-то поставить на сервера, чтобы управлять монгой по HTTP?
А putty не справляется?
Alexander
putty - это не по HTTP
Anonymous
phpmoadmin.com
Ярослав
(node:14288) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [botrikltest-shard-00-02-hu7rh.mongodb.net:27017] on first connect [MongoNetworkError: connection 5 to botrikltest-shard-00-02-hu7rh.mongodb.net:27017 closed]
Как это решить?
Дмитрий
Привет! не подскажете как хранить подобные данные в монге? мне нужно хранить только некий номер и дату добавления этого номера в базу даннных. но чтобы максимально быстро я мог запросить по диапазону, например от 10000 до 100000 и он мне выдал этот список номеров максимально быстро или когда я запрошу дай номера по дате добавления от ... до ... чтобы выдал эти номера. я не знаю. вчера только монгу изучать начал.
Даниил (Onix)
Привет! не подскажете как хранить подобные данные в монге? мне нужно хранить только некий номер и дату добавления этого номера в базу даннных. но чтобы максимально быстро я мог запросить по диапазону, например от 10000 до 100000 и он мне выдал этот список номеров максимально быстро или когда я запрошу дай номера по дате добавления от ... до ... чтобы выдал эти номера. я не знаю. вчера только монгу изучать начал.
а ты уверен что тебе монга нужна? Я не силён в БД, но если у тебя данные которые можно уместить в простую таблицу типа "id - дата - номер" может тебе использовать скл или постгри?
Дмитрий
а ты уверен что тебе монга нужна? Я не силён в БД, но если у тебя данные которые можно уместить в простую таблицу типа "id - дата - номер" может тебе использовать скл или постгри?
думал монга полегче, поэтому ее использовать. мне супер быстро не нужно. мне чтоб "приемлемо" но с монгой, потому что ее пока изучаю.
Даниил (Onix)
а что за проект? ты с БД вообще не работал?
Даниил (Onix)
преимущества монги (для меня как разработчика сайтов) :
1) Работает через JS (хотя обычные sql не такой уж и сложный, по крайнй мере запись в базу и селекты из базы достаточно простые). Но в любом случае выборку из базы сделать проще на JS который я знаю
2) Может хранить разнородные данные. Если в обычном случае ты заперт в рамках "id - дата - номер" то с монгой кажд ый твой объект может иметь ключи со своими названием. (Это позволит в перспективе просто расширять свою базу)
Roman
Даниил (Onix)
Мне это незнакомо, я совсем немножко умею в бд пока что.
Дмитрий
преимущества монги (для меня как разработчика сайтов) :
1) Работает через JS (хотя обычные sql не такой уж и сложный, по крайнй мере запись в базу и селекты из базы достаточно простые). Но в любом случае выборку из базы сделать проще на JS который я знаю
2) Может хранить разнородные данные. Если в обычном случае ты заперт в рамках "id - дата - номер" то с монгой кажд ый твой объект может иметь ключи со своими названием. (Это позволит в перспективе просто расширять свою базу)
поэтому хочу ее использовать. я сделал что у меня мои номера(это на самом деле адишки из одного сервиса) будут в монге ее _id. уже сделал так, но не знаю есть ли в этом смысл. вот моя схема если поможет понять мою идею:"const artistIdsSchema = new mongoose.Schema({
_id: { type: Number, required: true },
dateAdded: { type: Date, default: Date.now }
}, { _id: false });" я думал так быстрее будет. с базами не работал.
Dmitriy
А что с целостностью/непротиворечивостью данных?
так же как и в рсубд, если нет головы, то там можно такой треш устроить
Roman
так же как и в рсубд, если нет головы, то там можно такой треш устроить
Ну я про наличие констрейнтов в монге
Dmitriy
наличие констрейнов в рсубд не означает их использование в реальности, сколько таких проектов на практике встречал. и при вопросе, а почему лид был готов объяснить почему такое решение было выбрано (при этом я не говорю о спорности или нет выбранного решения (к слову сказать в ряде SOA проектов это было вполне себе обосновано)).
Дмитрий
наличие констрейнов в рсубд не означает их использование в реальности, сколько таких проектов на практике встречал. и при вопросе, а почему лид был готов объяснить почему такое решение было выбрано (при этом я не говорю о спорности или нет выбранного решения (к слову сказать в ряде SOA проектов это было вполне себе обосновано)).
не обязательно то что работает, работает правильно. их решения работают, или работают плохо, но никто из них не знает что лучше можно. бывает что работает, никто не знает что лучше можно, но бизнес терпит крах. может если б правильно работало, бизнес даже в гору шол бы. а бывает что и вообще не зависит от технических тех или иных решений, бизнес был обречен, по причине неправильного бизнес-плана и техническая сторона тут не причем.
Dmitriy
не обязательно то что работает, работает правильно. их решения работают, или работают плохо, но никто из них не знает что лучше можно. бывает что работает, никто не знает что лучше можно, но бизнес терпит крах. может если б правильно работало, бизнес даже в гору шол бы. а бывает что и вообще не зависит от технических тех или иных решений, бизнес был обречен, по причине неправильного бизнес-плана и техническая сторона тут не причем.
я об этом выше написал, что я тут не пытаюсь вынести на дискуссию правильность или не правильность решений в тех проектах, которые мне доводилось видеть)
а по поводу бизнеса, вот честно мое мнение и та практика с которой мне доводилось встречаться, бизнес терпит крах, когда не умеет себя продавать. а если продавать умеет, то и тетрис может продать как дьябло 8
Roman
наличие констрейнов в рсубд не означает их использование в реальности, сколько таких проектов на практике встречал. и при вопросе, а почему лид был готов объяснить почему такое решение было выбрано (при этом я не говорю о спорности или нет выбранного решения (к слову сказать в ряде SOA проектов это было вполне себе обосновано)).
Наличие законов не означает из выполнение. Но констрейнты дают инструмент, позволяющий добавить порядка.
yopp
Связанные сущности, например.
С появлением транзакций вы это можете в своём приложении реализовать
Dmitriy
Наличие законов не означает из выполнение. Но констрейнты дают инструмент, позволяющий добавить порядка.
да, но речь то о том, что каждый инструмент надо подбирать под задачу, чтобы не забивать микроскопом гвозди
Dmitriy
монга в данном случае хороша там где не нужна жесткая схема данных и безусловная связанность данных (ну или разработчик понимает как связанность обеспечивать на уровне приложения)
yopp
Но причём тут это к вопросу как хранить айдишники с датами
Roman
С появлением транзакций вы это можете в своём приложении реализовать
А чем они мне помогут? Вот каноничный пример: бложик с комментариями к статьям. Комментарии не могут висеть в воздухе.
yopp
поэтому хочу ее использовать. я сделал что у меня мои номера(это на самом деле адишки из одного сервиса) будут в монге ее _id. уже сделал так, но не знаю есть ли в этом смысл. вот моя схема если поможет понять мою идею:"const artistIdsSchema = new mongoose.Schema({
_id: { type: Number, required: true },
dateAdded: { type: Date, default: Date.now }
}, { _id: false });" я думал так быстрее будет. с базами не работал.
Оставьте _id как есть и ваш id запишите в отдельное поле и норм
yopp
А чем они мне помогут? Вот каноничный пример: бложик с комментариями к статьям. Комментарии не могут висеть в воздухе.
Тем что вы можете этот констрейн реализовать в приложении.
yopp
А чем они мне помогут? Вот каноничный пример: бложик с комментариями к статьям. Комментарии не могут висеть в воздухе.
И второй вопрос: что будет если комментарий повиснет в воздухе?
Roman
Тем что вы можете этот констрейн реализовать в приложении.
А потом ещё раз в другом. А потом в третьем
Dmitriy
А чем они мне помогут? Вот каноничный пример: бложик с комментариями к статьям. Комментарии не могут висеть в воздухе.
сколько пользователей в бложике, как много комментариев у каждого пользователя? в простейшем случае вы можете все хранить в одной коллекции, включая сам коментарий и пользователя
yopp
Нет, я не против чтоб в монгу завезли ещё инструментов для гарантий
Roman
И второй вопрос: что будет если комментарий повиснет в воздухе?
Мусор в бд. Не, можно пробежаться по всем статьям и найти все комментарии не привязанные к статьям
Roman
сколько пользователей в бложике, как много комментариев у каждого пользователя? в простейшем случае вы можете все хранить в одной коллекции, включая сам коментарий и пользователя
А потом упереться в лимит в 16мб на документ
yopp
В монге финансовы данные отлично хранятся
yopp
Но на той парадигме, которую предлагают типичные табличные хранилища, мир не заканчивается. Гарантии нужны не всегда и не везде. Очень часто эти гарантии используются без какого-то реального смысла
Тоже самое касалось транзакций. Они реально нужны в очень узком количестве случаев
Dmitriy
В монге финансовы данные отлично хранятся
подтверждаю, последний проект как раз про это и основное хранилище монга
Roman
Но на той парадигме, которую предлагают типичные табличные хранилища, мир не заканчивается. Гарантии нужны не всегда и не везде. Очень часто эти гарантии используются без какого-то реального смысла
Тоже самое касалось транзакций. Они реально нужны в очень узком количестве случаев
Окей, но раньше у нас было либо nosql, либо реляционные бд. А сейчас есть jsonb в pg и можно совмещать лучшее из обоих миров в одной бд.
Вообще, мне больше интересно было узнать про механизмы целостности в монге
Dmitriy
Окей, но раньше у нас было либо nosql, либо реляционные бд. А сейчас есть jsonb в pg и можно совмещать лучшее из обоих миров в одной бд.
Вообще, мне больше интересно было узнать про механизмы целостности в монге
про jsonb в pg поддержу, но в данном случае больши преимуществом монги по сравнению с pg будет шардирование и репликация из коробки. в pg без пляски с бубном к сожалению не обойтись