Объясни если не сложно

ну например

mysql более детская, а посгрес типа интерпрайс

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

mysql никогда такого даже близко не сможет

А что по гибкости?

постгрес гибче намного

есть свои фичи

типа поля, в которых можно хранить JSON и так же по нему искать

что даёт большое приемущество

чего в обще нет в mysql

там много всего

постгрес гибче, но сложнее, и настройка тоже требует время

постгрес гибче намного

Вот это подробнее если можно

и да, mysql уже давно никто не пользует, давно берут MariaDB - это тот же mysql от тех же разрабов, но быстрее

Вот это подробнее если можно

тогда подожди минут 15, пойду умоюсь, только встал

Привет, Мастериус! Как сюда попал? (правила у @jesus_bobot)

Да, МариюДБ надо юзать вместо мускуля. Она по эффективности во многом выигрывает, а синтаксис тот же. + в ней можно сразу же строить полноценные кластеры

а arangodb.com кто-то юзал? интересует опыт железо/количество данных

а arangodb.com кто-то юзал? интересует опыт железо/количество данных

а в чём её приемущество перед Mongo?

а в чём её приемущество перед Mongo?

их не совсем коректно сравнивать в принципе, потому, что разные типы БД, но вообще https://www.arangodb.com/performance/ https://www.arangodb.com/why-arangodb/arangodb-vs-mongodb/

и да, mysql уже давно никто не пользует, давно берут MariaDB - это тот же mysql от тех же разрабов, но быстрее

MySQL ламповые новички либо как старую зависимость уже давным давно юзают

я сам не использовал, только изучал, потому что нужно выбрать БД на замену МарииДБ, которая плохо справляется с след задачей: под 45кк записей, запросы делаются по периоду даты+еще разным полям, вида select * from table where (payer_name=Vasay or recipt_name=Vasya) and date between date1 and date2 из-за того, что в первом условии стоит or, то индекс по трем полям не создать, а отдельные индексы неэффективны, лучшее, что я придумал, это проиндексировать пары payer_name/date, recipt_name/date и делать два запроса, но все равно один такой запрос может занимать неск секунд, что конечно лучше, чем 20 минут, но все равно много. железо: ажур 2 ядра, 8 памяти кроме того сейчас используется самописная структура для хранения данных, что-то типа графовой БД и монга. а в будущем будет еще больше разных данных, которые надо еще связать между собой ключами. поэтому смотрим в сторону графивых БД, среди них судя по отзывам с нета аранго выгляд перспективней всего, особенно тем, что она не чисто графовая, а типа мультипарадигменная p.s. раз уж зашла речь о БД пишу, сори за много текста, может кто что подскажет

я сам не использовал, только изучал, потому что нужно выбрать БД на замену МарииДБ, которая плохо справляется с след задачей: под 45кк записей, запросы делаются по периоду даты+еще разным полям, вида select * from table where (payer_name=Vasay or recipt_name=Vasya) and date between date1 and date2 из-за того, что в первом условии стоит or, то индекс по трем полям не создать, а отдельные индексы неэффективны, лучшее, что я придумал, это проиндексировать пары payer_name/date, recipt_name/date и делать два запроса, но все равно один такой запрос может занимать неск секунд, что конечно лучше, чем 20 минут, но все равно много. железо: ажур 2 ядра, 8 памяти кроме того сейчас используется самописная структура для хранения данных, что-то типа графовой БД и монга. а в будущем будет еще больше разных данных, которые надо еще связать между собой ключами. поэтому смотрим в сторону графивых БД, среди них судя по отзывам с нета аранго выгляд перспективней всего, особенно тем, что она не чисто графовая, а типа мультипарадигменная p.s. раз уж зашла речь о БД пишу, сори за много текста, может кто что подскажет

А выбор изначально стоял меж DB?

А выбор изначально стоял меж DB?

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

Доброе утро

такой забавный момент во сне был)

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

Переходите на postgreSQL

Переходите на postgreSQL

+

но её надо уметь готовить!

но её надо уметь готовить!

Да

Но окупит собой переход более чем

Maria забавная, но не более

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

экспертиза чатика поражает

экспертиза чатика поражает

ты о чём

такой забавный момент во сне был)

доброе, что, база данных приснилась?

не, я с какой-то женщиной говорил по английски

достаточно вяло, но сносно говорил

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

я сам не использовал, только изучал, потому что нужно выбрать БД на замену МарииДБ, которая плохо справляется с след задачей: под 45кк записей, запросы делаются по периоду даты+еще разным полям, вида select * from table where (payer_name=Vasay or recipt_name=Vasya) and date between date1 and date2 из-за того, что в первом условии стоит or, то индекс по трем полям не создать, а отдельные индексы неэффективны, лучшее, что я придумал, это проиндексировать пары payer_name/date, recipt_name/date и делать два запроса, но все равно один такой запрос может занимать неск секунд, что конечно лучше, чем 20 минут, но все равно много. железо: ажур 2 ядра, 8 памяти кроме того сейчас используется самописная структура для хранения данных, что-то типа графовой БД и монга. а в будущем будет еще больше разных данных, которые надо еще связать между собой ключами. поэтому смотрим в сторону графивых БД, среди них судя по отзывам с нета аранго выгляд перспективней всего, особенно тем, что она не чисто графовая, а типа мультипарадигменная p.s. раз уж зашла речь о БД пишу, сори за много текста, может кто что подскажет

И да, у вас кэш вообще реализуется?

но самое смешное, что она мне же тоже отвечала

и у нее был очень хороший англ

но это же мой сон)

И да, у вас кэш вообще реализуется?

только то, что МарияБД сама кеширует

но это же мой сон)

:))

только то, что МарияБД сама кеширует

Над конфигом, то есть, особо никто не сидел?

Над конфигом, то есть, особо никто не сидел?

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

Просто тут ситуация, что 7 человек потратили месяц на переход на постгрес

И я уже пошел орать

Просто тут ситуация, что 7 человек потратили месяц на переход на постгрес

А с чего переходили?

А с чего переходили?

просто захотелось им, нет контроля

А с чего переходили?

у них в обще нагрузки нет

То есть просто взяли и дескать: постгрес, блять!

То есть просто взяли и дескать: постгрес, блять!

ага :)))

Потешно

Потешно

меня тоже улыбнуло

звучит как тост

просто взяли и дескать: постгрес, блять!

пора уже цитатник бородача состовлять

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

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

/pidor

Согласно моей информации, по результатам сегодняшнего розыгрыша пидор дня - senkevich_lex!

А вообще, было бы славно, ежели бы взяли какого-нибудь бандита, что возьмёт на себя задачи по обслуживанию базы

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

ERROR: S client not available

Сигна Бот первую букву начал искажать - кажеться у вашего бота появился разум

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

Главное данные не потеряйте, ибо и такое бывает.

Ору ребят

типа поля, в которых можно хранить JSON и так же по нему искать

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

Главное данные не потеряйте, ибо и такое бывает.

с этим все нормально, у нас и так процентов 5-10% потеряно уже (но можно восстановить), а за замечание спасибо

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

+

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

это же как бонус, всмысле, не чисто же PSQL ради JSON'а?

это же как бонус, всмысле, не чисто же PSQL ради JSON'а?

ну конечно

это же как бонус, всмысле, не чисто же PSQL ради JSON'а?

Да, фишка, грубо говоря

Чисто для JSON/BSON via protobuf лучше юзать что-то иное от PSQL

например, монгу или что-то другое? есть статьи, где на нее сильно гонят, с другой же стороны она очень популярна

@nof1000 решил пробежать курс по С++. Смутил в тесте пункт

например, монгу или что-то другое? есть статьи, где на нее сильно гонят, с другой же стороны она очень популярна

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

@nof1000 решил пробежать курс по С++. Смутил в тесте пункт

Ты зачитывал, что я тебе вчера скидывал?

почему в тесте считается неверным утверждение, что деструктор не имеет имени?

например, монгу или что-то другое? есть статьи, где на нее сильно гонят, с другой же стороны она очень популярна

Ну Mongo это хорошо, но не всегда

Ты зачитывал, что я тебе вчера скидывал?

ты про книги?

Если ты делаешь medium — тебе идеально зайдёт Mongo

Даже задумываться не надо

Если ты делаешь, что-то в виде target with parent key-value системы, то тут уже нужно хорошенько подумать, прежде чем выбрать Mong`у

ты про книги?

Да

нет еще, они же не маленькие)

почему в тесте считается неверным утверждение, что деструктор не имеет имени?

А почему он имеет?

хз, тест утверждает, что имеет

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

Ну конструктор ведь должен иметь имя идентичное имени класса, верно?

Если ты делаешь, что-то в виде target with parent key-value системы, то тут уже нужно хорошенько подумать, прежде чем выбрать Mong`у

не совсем понял и нагуглил, имеются ввиду внешние ключи или что?

Имя деструктора работает по таким же правилам, только имеет приставку ~

Но деструктор можно считать ограниченным методом

не совсем понял и нагуглил, имеются ввиду внешние ключи или что?

Что-то вроде графов, но на самом деле, ассоциативно-вложенные данные

Для geo point, например, идеально заходит

Когда нужно строить маршруты