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

Вопрос интересный, но при прочих равных если нечем заняться, то смысл есть )

ага, особенно туда и обратно )

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

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

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

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

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

В мускуле ж тоже есть поддержка таймзон, или не?

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

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

А репликация тоже впорядке, с полпинка?

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

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

Не, с таймзонами проблем не встречал в мускуле

А репликация тоже впорядке, с полпинка?

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

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

Это я)

ну в качестве основы = https://habrahabr.ru/post/106872/

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

Просто до этого работал с мускуле в большинстве, и с ораклом

вот и научитесь. репликация вас волновать не должна. у postgres другой нюанс - у него очень жирные коннекты. рецепты pgbouncer/pgpool

Не, с таймзонами проблем не встречал в мускуле

может, вы их просто не хранили? потому что datetime не хранит ничего кроме дмг чмс

вот и научитесь. репликация вас волновать не должна. у postgres другой нюанс - у него очень жирные коннекты. рецепты pgbouncer/pgpool

Я не против на ты;-) в общем пока реплика не нужна, но уже сразу думаю о таком сценарии

всегда нужна. иначе нет прода

"до первого бэкапа"

эмм, 2016, скоро 2017, hstore?

jsonb, да, я их путаю, сорри)

может, вы их просто не хранили? потому что datetime не хранит ничего кроме дмг чмс

Не буду спорить) но пока не встречал проблем

hstore вроде и сейчас быстрее jsonb на своих типах данных

всегда нужна. иначе нет прода

Оке, спасибо

и там и там Gin индексы вроде

если с индексами, то да. и вообще, я фигней страдаю. у нас hstore нет, и не хочется, да.

hstore вроде и сейчас быстрее jsonb на своих типах данных

ну да, хотя может глучнее ещё, то я как=то его вывалив в исключение =)

Да, 1 таблицу с 1 полем jsonb и все там хранить.

1 таблицу вместо нескольких таблиц с наследованиями друг от друга

хранить отличающиеся поля

те, которые повторяются, хранить как обычно

Да вполне прекрасный вариант

Оно от этого факта медленнее не стало

Стало. tarantool например.

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

оп, снова к тарантулу пришли

Гг он прекрасен

те, которые повторяются, хранить как обычно

Я думал наследование в постгрес это на уровне ddl. Ведь тогда кол-во строк во всех таблицах должно быть одинаковым.

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

всем привет. короче я так и не решил проблему. нашел способ с помощью dblink, но почему-то он не работает. в pgadmin 3 пишу INSERT INTO "Type" SELECT * FROM dblink('dbname=blablabla','SELECT * FROM Type') postgres ругается на dblink, хотя я создал расширение CREATE EXTENSION dblink; и при выполнение SELECT dblink_connect(‘host=localhost user=USER password=PW dbname=DB’); у меня коннект проходит(логин, пароль и бд подставляю свои). в папке contrib лежит только pldbgapi.sql, а в extension dblink--1.0.sql, dblink.control, dblink--unpackaged--1.0.sql что ему еще нужно чтобы заработала команда dblink?

алиас нужно сделать на то, что приходит из дблинка

http://www.dbrnd.com/2015/05/postgresql-cross-database-queries-using/ прям в точности весь процесс как в этом примере?

т.е. что-то типа SELECT id FROM dblink ('dbname=DB', 'SELECT di FROM t') AS u (id)

а если мне все поля надо перенести?

их все описывать?

http://www.dbrnd.com/2015/05/postgresql-cross-database-queries-using/ прям в точности весь процесс как в этом примере?

зачем вместе FDW и dblink?

их все описывать?

да

зачем вместе FDW и dblink?

я не знаю. просто нашел пример и пытаюсь по нему сделать у себя

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

если не прокатит, то уже все

хорошо

Тогда постгрес в своих сообщениях должен вставлять постоянно ", извините" :)

и делать все меееееедленно

? Почему медленно то?

То, что он стабильно стоял и не дергался не говорит о его медлительности

недавно общался с тимлидом одной команды в mail.ru, попутно зашла речь о KV, напомнил, что у них есть Tarantool, в ответ - так он же глючный ) в общем, в брокера сообщений его не стали рассматривать (хотя там есть tarantool-queue).

недавно общался с тимлидом одной команды в mail.ru, попутно зашла речь о KV, напомнил, что у них есть Tarantool, в ответ - так он же глючный ) в общем, в брокера сообщений его не стали рассматривать (хотя там есть tarantool-queue).

А кого стали рассматривать?

в основном смотрят на RabbitMQ (и используют), хотя я честно рекомендовал Apache Kafka. Ну и, понятно, что кое-где у них есть и ZeroMQ.

ну, rabbit и kafka чуть более чем разные штуковины

они, кстати, обещали 25 выкатить "убийцу" Oracle (Tarantool + вкаряченый внутрь SQLite), получилось что-нибудь ?

думаю, детали зависят от проекта. я рассматривал производительность и надёжность.

по обоим критериям RabbitMQ уступает imho.

он объективно уступает по этим показателям, что уж там, но, конечно, по функциональности на AMQP

они, кстати, обещали 25 выкатить "убийцу" Oracle (Tarantool + вкаряченый внутрь SQLite), получилось что-нибудь ?

там по фото человка, выпустившего это заявление, уже было все понятно

там по фото человка, выпустившего это заявление, уже было все понятно

что понятно?

что не убийца и не выпустят

читаешь по лицам, гадаешь по ладони?)

Так они уже отписались, что самую малость задерживается акт убиения.

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

в основном смотрят на RabbitMQ (и используют), хотя я честно рекомендовал Apache Kafka. Ну и, понятно, что кое-где у них есть и ZeroMQ.

zmq может использовать только очень невменяемый человек.

по обоим критериям RabbitMQ уступает imho.

кролик и кафка - для разных сценариев. есть хороший ответ от одного из авторов кролика про плюсы/минусы обеих систем.

zmq может использовать только очень невменяемый человек.

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

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

да каждый о своем продукте кричит))

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

Так и будет

кролик и кафка - для разных сценариев. есть хороший ответ от одного из авторов кролика про плюсы/минусы обеих систем.

можно урл?

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

Я использовал и больше не хочу. Почему-то многие кто так делал больше не хотят связываться с zmq.

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

Дабл фейспалм. 1) постгрес его импортозаместит. 2) Зачем вы смешиваете реляциионные СУБД со всяческими хипстерскими key-value?

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

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

А потом выесняется, что эти хипстеры закинули все в оперативку и потому все шустрое

Толсто и жирно

Дабл фейспалм. 1) постгрес его импортозаместит. 2) Зачем вы смешиваете реляциионные СУБД со всяческими хипстерскими key-value?

Лишь бы потрындеть

Ну есть мнение, что те же файлы хранить в БД глупо, а в том же кey-value не так уж глупо учитывая, что он умеет шардинг.... Берешь реляционку и хранишь в ней key - а value в какой-нибудь noSQL

Nosql удобнее во многих кейзаз

Это один из юзкейсов

Банальное хранение json подступающего в монгу

Nosql удобнее во многих кейзаз

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

Это один из юзкейсов

В смысле - бородатый мальчик, не понимающий, чем left join отличается от inner?

В смысле - бородатый мальчик, не понимающий, чем left join отличается от inner?

Это сейчас о чем?

Это сейчас о чем?

Это толстый троль

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

Кассандра хорошо вместе со спарком агрегирует все :)

Банальное хранение json подступающего в монгу

Это до тех пор, пока вам не нужно селектить эти json по неключевому значению. Когда становится нужно - вас увольняют и нанимают SQL-щиков :)

Кассандра хорошо вместе со спарком агрегирует все :)

Ага и трахаешься с горизонтальным масштабированием

Это до тех пор, пока вам не нужно селектить эти json по неключевому значению. Когда становится нужно - вас увольняют и нанимают SQL-щиков :)

Queries first построение

И живите счастливо

Ага и трахаешься с горизонтальным масштабированием

Чем вас не устраивает масштабирование по датацентрам ракам и прочими прелестями из коробки ?

Как только у вас много данных нужен nosql

Чем вас не устраивает масштабирование по датацентрам ракам и прочими прелестями из коробки ?

Репликами и распараллелированием

Репликами и распараллелированием

Так оно все реплицируется и параллелится прекрасно

Есть тот же hive

Как только у вас много данных нужен nosql

Вообще то у nosql определение "нет четкой структуры", а не когда много данных