Comments 20
Интересный пост, спасибо. Стоунбрейкер вызывает восхищение, конечно — столько проектов и такие результаты.
Сейчас прилично сервисов по подборке комбинаций технологий для стартапов, но вот реальным опытом (на русском особенно) мало кто делится. Буду ждать подобных тем в вашем блоге, спасибо!
Это всё хорошо конечно, но как же бенчмарки?
PostgreSQL считается постреляционной системой. И действительно весьма хорош.
Не очень понял, при чем тут стартап? Да, конкретному проекту Като подошла традиционная SQL база PostgreSQL. Отлично, но это, ИМХО, отнюдь не повод утверждать, что «реляционные СУБД отлично подходят для стартапов». Это как сказать, что PHP для стартапов лучше Ruby.
Стартапы часто меняют стратегию — это значит, что им лучше пользоваться гибкими инструментами (а не модными и хорошо подходящими для узких сегментов задач). Если говорить о СУБД, то здесь PostgreSQL, на наш взгляд, больше подходит для создания и масштабирования новых ИТ-проектов.
Естественно, это только наше мнение, а не истина в последней инстанции).
Естественно, это только наше мнение, а не истина в последней инстанции).
Это очень хорошее и правильное мнение.
Современный Постгрес позволяет сочетать строгость схемы там, где это очень-очень желательно (условная табличка users с нужными ограничениями целостности) и гибкость там, где схема должна часто меняться — как в вашем примере с сообщениями. А главное, всё это со строгой реализацией ACID.
Статья отличная, только хотелось бы побольше «техники», но это чисто моя хотелка.
А вы в итоге уже используете 9.4 и jsonb или в бою пока только hstore?
Современный Постгрес позволяет сочетать строгость схемы там, где это очень-очень желательно (условная табличка users с нужными ограничениями целостности) и гибкость там, где схема должна часто меняться — как в вашем примере с сообщениями. А главное, всё это со строгой реализацией ACID.
Статья отличная, только хотелось бы побольше «техники», но это чисто моя хотелка.
А вы в итоге уже используете 9.4 и jsonb или в бою пока только hstore?
Поддержка JSON была и в 9.2, в 9.4 появился JSONB, поддержка индексов и расширенный набор функций.
Согласен с автором, некоторое время назад начал проект с MongoDB, теперь подумываю вернуться к старому-доброму Postgres. С реляционной СУБД можно делать всё, что угодно – а NoSQL накладывает свои ограничения, которые могут помешать реализации новых фич в продукте, не предусмотренных на этапе начального планирования. К тому же согласно бенчмаркам Postgres обходит Mongo в производительности.
Ждал увлекательный рассказ про гибкость реляционной модели, а получил экскурс в историю и описание какого-то костыля к PostgreSQL.
Те же запросы в менее реляционной базе выглядят куда более наглядно.
Создаём класс и свойство:
Создаём докумет:
Обновляем вложенное значение:
Читаем вложенное значение:
Те же запросы в менее реляционной базе выглядят куда более наглядно.
Создаём класс и свойство:
create class hstore_test
create property hstore_test.data embeddedmap string
Создаём докумет:
insert into hstore_test content { "data" : { "a" : "hello" , "b" : "world" } }
Обновляем вложенное значение:
update hstore_test set data.b = 'world!'
Читаем вложенное значение:
select data.b from hstore_test
А есть ли для postgres master-master репликация простая в настройке? В интернете часто встречаю статьи про танцы с бубнами. Причем желательно вставлять данные в оба мастера и чтобы это работало между 2-мя ЦОДами, пусть не быстро но стабильно.
Ну и еще вопрос в догонку ) Вот есть у меня несколько таблиц (штук 5) которые джоинятся чтобы получить итоговый результат. В одной из таблиц штук 15 столбцов и по каждому столбцу индекс (т.к. хотим сортировать по любому столбцу). Теперь вопрос: сколько максимально записей можно хранить в такой таблице на хорошем выделенном серваке с ssd дисками, 256г оперативки и т.д. Чтобы база хоть как-то шевелилась. Ну приблизительно порядок хотябы. Подойдет ответ в стиле «более 100 млн не рекомендуется, возможны тормоза...». Спасибо!
Ну и еще вопрос в догонку ) Вот есть у меня несколько таблиц (штук 5) которые джоинятся чтобы получить итоговый результат. В одной из таблиц штук 15 столбцов и по каждому столбцу индекс (т.к. хотим сортировать по любому столбцу). Теперь вопрос: сколько максимально записей можно хранить в такой таблице на хорошем выделенном серваке с ssd дисками, 256г оперативки и т.д. Чтобы база хоть как-то шевелилась. Ну приблизительно порядок хотябы. Подойдет ответ в стиле «более 100 млн не рекомендуется, возможны тормоза...». Спасибо!
Да, есть — вот свежее решение 2ndquadrant.com/en/resources/bdr/
то есть у вас postgres используется как для хранения так и для поиска по сообщениям?
рассматривали вы elasticsearch и другие подобые системы? если да, то почему не взяли в использование?
рассматривали вы elasticsearch и другие подобые системы? если да, то почему не взяли в использование?
Да, как для хранения, так и для поиска.
У нас была задача сделать максимально быстрый и точный поиск с возможностью показывать контекст (что было сказано до или после найденного) — постгрес удалось заставить это сделать очень быстро, с результатом, который был лучше все других подобных решений, которые мы изучили. Но тут и проблема есть — с азиатскими языками токенизатор не работает.
У нас была задача сделать максимально быстрый и точный поиск с возможностью показывать контекст (что было сказано до или после найденного) — постгрес удалось заставить это сделать очень быстро, с результатом, который был лучше все других подобных решений, которые мы изучили. Но тут и проблема есть — с азиатскими языками токенизатор не работает.
Sign up to leave a comment.
Почему реляционные СУБД отлично подходят для стартапов: Пример из истории разработки мессенджера Kato