доброго времени суток.
Вопрос относительно организации бд и схем в postgre
Предположим у нас есть приложение, в нем регистрируются юзеры допустим та же соц сеть. Допустимо ли под отдельного юзера создавать отдельную схему? Т.е. в ней будут содержаться таблицы связанные лишь с этим юзером, в них его инфа.
Полная Версия: Схемы в postgre
Если честно, то не знаю, сколько возможно сделать схем в постгре. Но считаю, что это будет изврат 
Если тебе очень хочется разнести данные, то сделай партиции. Они в постгре лучше делаются, красивее и удобнее, чем в мускуле.
Хотя, конечно, под каждого юзера делать свою партицию, да еще если и в нескольких таблицах, это изврат будет.
Ты лучше скажи, зачем тебе это нужно?
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Если тебе очень хочется разнести данные, то сделай партиции. Они в постгре лучше делаются, красивее и удобнее, чем в мускуле.Хотя, конечно, под каждого юзера делать свою партицию, да еще если и в нескольких таблицах, это изврат будет.
Ты лучше скажи, зачем тебе это нужно?
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
дак задачу описал, сервис в нем юзеры, могут добавлять информацию и работать с ней привлекая вычислительные ресурсы сервиса.
При этом нужно понимать что 1 юзер может завести много проектов, и нужно предусмотреть быстрый механизм архивирования и раз архивирования этих проектов.
И в принципе юзеры могу удаляться, т.е. всю инфу юзера придется удалять по всем рабочим таблицам. Вот в этом и вопрос) логически понятно, что для 1 юзера лучше создать 1 хранилище, это должно быть и более производительно и менее накладно в плане дальнейшие работы с данными описанными выше.
А партиции можно применить для проектов.
Я просто может ошибаюсь?
дак задачу описал, сервис в нем юзеры, могут добавлять информацию и работать с ней привлекая вычислительные ресурсы сервиса.
При этом нужно понимать что 1 юзер может завести много проектов, и нужно предусмотреть быстрый механизм архивирования и раз архивирования этих проектов.
И в принципе юзеры могу удаляться, т.е. всю инфу юзера придется удалять по всем рабочим таблицам. Вот в этом и вопрос) логически понятно, что для 1 юзера лучше создать 1 хранилище, это должно быть и более производительно и менее накладно в плане дальнейшие работы с данными описанными выше.
А партиции можно применить для проектов.
Я просто может ошибаюсь?
Ты мне вот что скажи для начала: как ты представляешь, что такое партиции? И не надо цитировать гугл Меня интересует именно твое личное мнение/ощущение/знание.
А потом я скажу свое мнение о партициях, как их тут можно применить.
PS. Я не говорю, что создание схемы для каждого юзера неправильно. Возможно, это как раз более правильно. Но чтобы это понять, надо сначала оценить оба подхода, их плюсы и минусы.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Меня интересует именно твое личное мнение/ощущение/знание.А потом я скажу свое мнение о партициях, как их тут можно применить.
PS. Я не говорю, что создание схемы для каждого юзера неправильно. Возможно, это как раз более правильно. Но чтобы это понять, надо сначала оценить оба подхода, их плюсы и минусы.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
хорошо, хорошо, что-то вроде кластеризации диска
сейчас проверю себя в гугле)
сейчас проверю себя в гугле)
sergeiss
PS. Я не говорю, что создание схемы для каждого юзера неправильно. Возможно, это как раз более правильно. Но чтобы это понять, надо сначала оценить оба подхода, их плюсы и минусы.
обмен информацией между пользователями минимальный т.е. просто чат, функционал сервиса для всех пользователей одинаков.
Т.е. структура таблиц для хранения информации будет одна. Потребуется частое удаление большого объема информации и такая же частая заливака скажем с csv файла.
я бы не стал топики плодить и париться, запустил партиции по юзер id в списке товаров в общей таблице и трава не расти, но именно вот это исключение большого объема данных и быстрое возвращение в базу и заставляет искать решения
PS. Я не говорю, что создание схемы для каждого юзера неправильно. Возможно, это как раз более правильно. Но чтобы это понять, надо сначала оценить оба подхода, их плюсы и минусы.
обмен информацией между пользователями минимальный т.е. просто чат, функционал сервиса для всех пользователей одинаков.
Т.е. структура таблиц для хранения информации будет одна. Потребуется частое удаление большого объема информации и такая же частая заливака скажем с csv файла.
я бы не стал топики плодить и париться, запустил партиции по юзер id в списке товаров в общей таблице и трава не расти, но именно вот это исключение большого объема данных и быстрое возвращение в базу и заставляет искать решения
hurt3, дабы не повторяться и не копипастить, я тебя просто "пошлю" в свою же тему, где я писал о партициях http://phpforum.su/index.php?showtopic=84298
Что касается сравнения схемы vs партиции для соцсети... Опиши, какие наиболее частые задачи могут возникать, иначе не получится сравнить. Плюсы-минусы есть у каждого решения.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
в свою же тему, где я писал о партициях http://phpforum.su/index.php?showtopic=84298Что касается сравнения схемы vs партиции для соцсети... Опиши, какие наиболее частые задачи могут возникать, иначе не получится сравнить. Плюсы-минусы есть у каждого решения.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата (hurt3 @ 15.01.2016 - 22:00) |
| обмен информацией между пользователями минимальный т.е. просто чат, функционал сервиса для всех пользователей одинаков. Т.е. структура таблиц для хранения информации будет одна. Потребуется частое удаление большого объема информации и такая же частая заливака скажем с csv файла. |
Это ты сейчас говоришь, что обмен инфой минимальный
Потом может появиться другая идея, которая приведет к существенному увеличению этого обмена. В случае полного отсутствия взаимообмена вполне подходят схемы. Но как только появляется взаимный обмен, то тебе придется, скорее всего, дублировать инфу в разных схемах. Поэтому в случае взаимообмена инфой лучше будут партиции. Там, в ряде таблиц, инфа будет в единственном экземпляре, но для разных юзеров.Далее. Предположим, что ты "вдруг" решил поменять структуру хотя бы одной таблицы. Или, еще веселее, структуру нескольких таблиц, связанных друг с другом. В случае схем тебе придется запускать команды на изменение столько раз, сколько у тебя схем, т.е. сколько юзеров. На это уйдет некоторое время, возможно очень немалое. В течение этого времени могут быть проблемы с выборкой и особенно с записью данных. То есть, БД придется закрыть для доступа. Для партиций это будет сделано только один раз, все партиции будут изменены одновременно.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
так допустим -это просто пример для понимания ситуации
есть сервис в нем есть юзеры
юзеры регятся и создают компании, в компаниях размещают товары ну и предположим сервис интегрирован с Яндекс маркетом, аналогичным решением гугла и рамблера.
Пользователи могу массово добавлять удалять и редактировать товары. Сервис производит ежеминутно сравнение цены с конкурентами и корректировку.
Давай в нагрузку пусть хранит отзывы о данном товаре которые находит на сторонних сайтах и дает им оценку по эмоциональной составляющей.
Соответственно компанию можно архивировать и нужно это сделать, так что бы рабочая таблица товаров меньше грузилась и что бы лишние компании не мешелись в работе юзеру и соответственно можно разархивировать, можно удалить можно загрузить из файла.
Ну и давай на всякий случай отметим, что однажды инфу по сервакам может понадобится разность.
Старые клиенты новые клиенты или иной варриант.
ну и конечно чат)
И вот, что получается допустим у нас регистрируются 10 000 человек каждый заводит 5-100 компаний. В одной компании ну пускай будет 20 тыс позиций товаров, товары заливаются, комментируются, оцениваются удаляются или удаляются пачками
вот здесь уже встает вопрос об уникальном id товара. У 2хюезров могут быть одинаковые товары, но это 2 разные позиции с точки зрения системы и они имеют разную сопутствующую инфомрацию -отзывы, оценки и прочее..
есть сервис в нем есть юзеры
юзеры регятся и создают компании, в компаниях размещают товары ну и предположим сервис интегрирован с Яндекс маркетом, аналогичным решением гугла и рамблера.
Пользователи могу массово добавлять удалять и редактировать товары. Сервис производит ежеминутно сравнение цены с конкурентами и корректировку.
Давай в нагрузку пусть хранит отзывы о данном товаре которые находит на сторонних сайтах и дает им оценку по эмоциональной составляющей.
Соответственно компанию можно архивировать и нужно это сделать, так что бы рабочая таблица товаров меньше грузилась и что бы лишние компании не мешелись в работе юзеру и соответственно можно разархивировать, можно удалить можно загрузить из файла.
Ну и давай на всякий случай отметим, что однажды инфу по сервакам может понадобится разность.
Старые клиенты новые клиенты или иной варриант.
ну и конечно чат)
И вот, что получается допустим у нас регистрируются 10 000 человек каждый заводит 5-100 компаний. В одной компании ну пускай будет 20 тыс позиций товаров, товары заливаются, комментируются, оцениваются удаляются или удаляются пачками
вот здесь уже встает вопрос об уникальном id товара. У 2хюезров могут быть одинаковые товары, но это 2 разные позиции с точки зрения системы и они имеют разную сопутствующую инфомрацию -отзывы, оценки и прочее..
sergeiss
спасибо я тебя понял, но на всякий случай посмотри, что вверху набросал, и вот то же вопрос ресурсов вариант со схемами будет жрать больше при хранении?
спасибо я тебя понял, но на всякий случай посмотри, что вверху набросал, и вот то же вопрос ресурсов вариант со схемами будет жрать больше при хранении?
| Цитата (hurt3 @ 15.01.2016 - 22:30) |
| будет жрать больше при хранении? |
Если контент будет дублироваться, то да, больше.
Я бы, думаю, выбрал партиции. Потому что в целом получается более гибкое решение. Архивировать и удалять можно и отдельные партиции, не только схемы, если тебе вообще это нужно.
При работе с партициями можно в явном виде указывать, с какой партицией ты работаешь. Например, в запросе по определенному юзеру можно указать только те партиции, которые "его". Это будет то же самое, что при запросе внутри отдельной схемы.
Да и вообще. Сделай пару тестовых БД. В одной сделай несколько схем, в другой - партиции. "Поиграйся" с ними, почувствуй разницу. И не забывай по ходу дела делиться с форумчанами своим опытом.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
т.е. ты имеешь виду что допустим унас будут просто таблицы в одной схеме.
при этом таблица товаров должна иметь партиции на юзера и его компанию?
Т.е. на связку 1юез+ 1 его компания будет создаваться своя партиция?
т.е. по сути дела 1 отдельная таблица?
т.е. ты имеешь виду что допустим унас будут просто таблицы в одной схеме.
при этом таблица товаров должна иметь партиции на юзера и его компанию?
Т.е. на связку 1юез+ 1 его компания будет создаваться своя партиция?
т.е. по сути дела 1 отдельная таблица?
Партиции - это части от одной таблицы, имеющие идентичную структуру и, возможно, связанные как-то логически. Если что, тебе надо создавать несколько разных наборов партиций, от каждой таблицы, где они вообще требуются.
И еще раз повторю - лучше сам создай партиции и схемы, "поиграйся" с ними. Иначе просто не прочувствуешь.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
И еще раз повторю - лучше сам создай партиции и схемы, "поиграйся" с ними. Иначе просто не прочувствуешь.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
спасибо
спасибо
пообщался с админами хостингов, говорят не желательно, на обычном хосте максимум 20 схем
Здесь расположена полная версия этой страницы.