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

Boris Korobkov, 10 таблиц и будет. Данные 100% типовые, что им делать в разных таблицах?
Дорастёт база до полутеррабайтного размера хотя бы - ну можно спилить что-нибудь горячее (или наоборот холодное) на отдельный кластер СУБД.
Или вы собираетесь убеждать DBA, ежедневно работающего с базами на несколько террабайт под нагрузкой в тысячи qps, что игрушечная табличка всего-то в десяток-другой гигабайт - это охренеть какой объём данных и ничего работать не будет?

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

Boris Korobkov, ммм. Какие 10000 таблиц? Вы о чём и откуда они взялись?

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

Boris Korobkov, ага. Да, это автоматизируется. И автоматизация обязательно добавит новых граблей, которых банально нет с одной большой базой. А понадобится ли вообще вторая база - ещё большой вопрос.

Вопрос по статье на Хабре про триггеры - могут ли гарантировать триггеры целостность данных?

Denis Popov, или вы говорите про какую-то одну конкретную субд или сильно заблуждаетесь.

триггер вешается только на одну операцию, их придется дублировать на инсерты, апдейты

Зависит от СУБД. postgresql не проблема повесить один триггер на пачку операций.

Все эти триггеры, представления, процедуры и т.п. очень сильно влияют на производительность...

Подчас весьма положительно влияют. Т.к. не тратим время на сеть и плюс СУБД может кэшировать план хранимок.

К примеру прямой запрос навороченный займет 0.004с, а с представлением это уже может быть уже 0.15с

it depends. Запрос к таблице и запрос к вьюхе может быть переписан в идентичный вид планировщиком. Но вьюхи вешаются не для производительности, а для удобства. Для производительности - материализованные вьюхи.

Почему не работает UNION ALL запрос?

Алекс Иванов, на самом деле самый обычный order by. Сортировать возможно по результату любого вычисления, вот здесь сортировка по 3 вычисляемым полям.
rank_golos >=22.1 desc - дополнительный фокус неявного приведения типов в mysql. Истинное условие - 1, ложное - 0. Что позволяет сортировать как число.

В мануале есть вот такой пример:

SELECT CONCAT(last_name,', ',first_name) AS full_name
  FROM mytable ORDER BY full_name;

Если select поля сортировки делать не надо, то

SELECT ..
  FROM mytable ORDER BY CONCAT(last_name,', ',first_name)

Полностью допустимый вариант записи, по синтаксису допустимо использовать ORDER BY {col_name | expr | position}. Но position deprecated, хотя местами может попадаться вот в таком виде как эквивалент обращения по имени поля

SELECT CONCAT(last_name,', ',first_name) AS full_name
  FROM mytable ORDER BY 1;

Почему не работает UNION ALL запрос?

обратите внимание на разный порядок полей в order by в вопросе

Не получается с заменой в preg_replace()?

json_decode и получаете нормальный массив или объект с которым делаете что пожелаете.

Не получается с заменой в preg_replace()?

А не json ли там случаем? К чему извращения с регулярками?

Pgpool2 multy-master mode где искать мануалы по настройке? Как вы масштабируете базу(под запись)?

Поделитесь пожалуйста советом как вы "распиливаете" базу штатной потоковой репликацией

Никак. Кластера полностью независимые между собой.

Приложение само решает, в какой кластер ему идти и так же само решает на какой тип машины идти: мастер, online реплика или slow реплика для возможно длительных запросов
Мастер никаким роутингом не занимается.

Как скинуть проверку жесткого диска на убунту?

anton_myaso, куда-куда. В логи, конечно.

Как скинуть проверку жесткого диска на убунту?

clean значит clean. Это не ошибка и ищете вы не там.

Postgresql+потоковый бекап: как победить проблему с правами на папку?

покажите ls -l /var/lib/postgresql/9.6/ с мастера и реплики. В нормальном виде должно быть (дата только своя):

drwx------ 19 postgres postgres 4096 ноя 14 11:28 main

Postgresql как ограничить общий размер WAL-файлов?

Тогда не трогайте настройки мастера кроме как max_wal_senders (если был выключен) (для basebackup необходимо минимум 2 коннекта). Ну и чуть-чуть wal_keep_segments всё-таки можно поднять.
По-умолчанию мастер не будет дожидаться реплику. Если мастеру хочется удалить wal - он их удалит как ни в чём не бывало. Если реплика этот wal не прочитала ещё - то получит потом отлуп и надо будет pg_basebackup делать заново. (для изменения этого поведения как раз replication slots и появились)

pg_basebackup -X stream открывает два соединения: по одному копирует базу, по второму подписывается на все новые wal как рядовая реплика. Поэтому во время его работы мастер работает как ни в чём не бывало и удаляет wal как обычно. А вот на реплике wal будут копиться. И стартовать реплика может немного не сразу, пока все эти wal проигрывает. Неприятный момент - за новыми wal к мастеру реплика пойдёт только когда разгребёт все локально записанные wal.

В общем, делается в screen pg_basebackup с ключом --progress, когда он доработал - открывается в другой консоли tail -f лога будущей реплики, запускается реплика и ждём ready to accept connections и starting streaming. Если посыпались ошибки wal segment already removed - стопаем реплику, на мастере поднимаем keep segments и пробуем налить реплику ещё раз. (у нас в dataegret обычно изначально keep segments задран)

Как избежать блокировки параллельных запросов в Postgresql?

21 секунду работали, 508 секунд ждали диски. Естественно если сюда добавлять ещё конкурентной нагрузки - будет только хуже.
explain видите? Глядя на него мысли повесить индекс-другой не возникает? Нет? А почему?

Как избежать блокировки параллельных запросов в Postgresql?

Моя рабочая гипотеза - у вас медленные механические диски и достаточно данных чтобы не помещаться в памяти. В таких условиях один запрос работающий 2 минуты в 10 потоков выполняться час может вполне. Потому что random io на механике - это всегда больно.

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

sql знаю на уровне запросов, по мне так больше знать и не нужно

explain это уровень именно запроса. И его вы как разработчик понимать должны. Потому что непосредственно работаете с базой. Тем более поскольку ДБА у вас в команде нет, который будет по рукам бить за совершение глупостей.

Как избежать блокировки параллельных запросов в Postgresql?

yuharu, как postgresql DBA поясняю: shared_buffers - это такая настройка postgresql. Чтобы не гадать, где та переопределяется и с чем база запущена - лучше про неё спросить саму запущенную базу запросом show shared_buffers. Explain - это explain. Как (судя по вопросу) разработчик работающий с СУБД вы должны знать что это. Дополнительные параметры за explain - это дополнительные параметры explain. Лучше бы разработчики о них тоже знали, ну да ладно. Это то, по чему можно много полезного и увлекательного узнать о проблемных запросах. track_io_timing - настройка, добавляющая ещё полезных данных в секцию buffers у explain. А больше ничего про базу я ещё не спросил, всё остальное обычные системные метрики которые надо узнать у сисадмина.

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

Как избежать блокировки параллельных запросов в Postgresql?

ну и explain (analyze,buffers) запроса при включенных track_io_timing может интересную информацию показать.

Как избежать блокировки параллельных запросов в Postgresql?

buffer_io Waiting for I/O on a data page.

https://www.postgresql.org/docs/9.6/static/monitor...

Какие диски? Добавьте в вопрос графики мониторинга с io util и iops. Или штук 5-10 листингов iostat -x 1 при выполняемых запросах.
Плюс сколько памяти всего (free -h) и сколько выделено shared_buffers

Не могу понять что не так? json_decode почему не работает?

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

Тяжелые команды для БД с большим количеством записей?

longclaps, именно только для myisam. Для мультиверсионного транзакционника innodb вопрос "сколько у тебя строк" не имеет смысла вообще. Имеет смысл "сколько версий строк видит моя транзакция". И без проверки каждой строки на видимость в конкретной транзакции это не узнать. В статистике же хранится приблизительное число строк.