@pgsql

Страница 26 из 1062
Alexey
14.05.2016
14:09:46
и особо эти нововедение не распробовал

Alexander
14.05.2016
14:31:42
смотри, если нет хотя бы 10 тыщ rps то тарантул не нужне
Например у меня больше, почему мне стоит выбрать тарантул а не VoltDB?

Александр
14.05.2016
14:32:31
Phil
14.05.2016
14:37:56
есть подозрение что Phil виндузятник
не надо ничего подозревать, я хорошо гуглюсь :)

Google
Александр
14.05.2016
14:41:00
Ну и вроде это не зазорно?

Или да?

Pavel
14.05.2016
14:44:04
Или да?
Нервничаешь? ?

Александр
14.05.2016
14:44:12
Ни

Pavel
14.05.2016
14:45:14
Сейчас не зазорно, тем более что видна начала мутировать в линукс

Александр
14.05.2016
14:45:19
У меня гетерогенная среда, например

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

Хотя это возможно

Под каждую задачу есть наиболее подходящий инструмент

Alex
14.05.2016
14:52:19
Да использование винды незазорно, но если ты вроде как системный администратор вроде как в хостинговых компаниях то вероятно знания юникса не сильно излишне.

*unix-like систем для особых эстетов

Vasily
14.05.2016
15:42:48
смотри, если нет хотя бы 10 тыщ rps то тарантул не нужне
Чат конечно не тот, но вот пытаюсь понять - Вы хотите в нишу CouchBase-а? Их вроде как используют как основную базу, у них синхронный коммит на столько нод, на сколько укажешь и т.д. Если Тарантул будет таким же - то это будет хорошо.

Konstantin
14.05.2016
15:48:16
Ыыыы... Ниша каучбейса. У него есть ниша? Это Франкенштейн из couchdb и memcache на стероидах ) И мы быстрее элак раз в 5 их.

Google
Vasily
14.05.2016
15:52:11
Ыыыы... Ниша каучбейса. У него есть ниша? Это Франкенштейн из couchdb и memcache на стероидах ) И мы быстрее элак раз в 5 их.
Ну, чего у него внутрях я только догадываюсь. Только вот они на каждом углу кричат, что их пользует Пейпал и ЛинкедИн. Да и я, чего греха таить, поставил в продакшене пару махоньких кластеров под кеши- снять нагрузку с реляционных баз. Просто Тарантула никогда не видел - вот и интересен его вектор развития.

Konstantin
14.05.2016
16:00:30
Мы не кеш.

Vasily
14.05.2016
16:00:53
Мы не кеш.
Ну это как приготовить :)

Konstantin
14.05.2016
16:00:55
Наша ниша сегодня - backend-free microservice

Александр
14.05.2016
16:01:01
Мы не сеем

Konstantin
14.05.2016
16:01:20
Когда база она же апп сервер и она же бэкенд для нагруженного проекта

Кэширование - антипаттерн если есть Тарантул

Vasily
14.05.2016
16:04:16
Когда база она же апп сервер и она же бэкенд для нагруженного проекта
Ок, я понял что надо идти, скачивать и смотреть :)

Кэширование - антипаттерн если есть Тарантул
А если есть реляционные базы, на которых написано куча логики и репортов, то вынос "мусорной" нагрузки необходимость - а паттерн это или антипатерн - неважно :)

Konstantin
14.05.2016
16:09:20
Кэширование - это не вынос нагрузки. Для выноса нагрузки Тарантул и создавался. Но нагрузку надо выносить вместе с данными. Иначе такой вынос - ло первого холодного рестарта

Или до первой баги синхронизации кэша и первоисточника

Vasily
14.05.2016
16:15:33
Кэширование - это не вынос нагрузки. Для выноса нагрузки Тарантул и создавался. Но нагрузку надо выносить вместе с данными. Иначе такой вынос - ло первого холодного рестарта
Есть задачи в которых данные можно потерять - например когда показываешь пользователям прогресс асинхронной задачи, которая выполняется на сервере на другом континенте - она бодро пишет свои логи под себя и в кеш. Кеш всегда можно перечитать из первоисточника, а после завершения работы таска все равно результат укладет в реляционную базу.

Konstantin
14.05.2016
17:26:15
Это не совсем пример кэширования. А "возможность потерять данные" это исключительно вопрос масштаба. Вот допустим есть такая штука, которая работает в 99.9% случаев. пока этот 0.1% не превращается в сотни недовольных пользователей, которые жмут Refresh потому что не видят progress bar - подход вроде как работает. А потом оказывается, что никто не оттестировал случай, когда кэш недоступен, что у ситуации ещё есть 100500 непредусмотренных последствий, т.к. в 99% случаях всё работает и никто не заморачивался на оставшийся 1%

Vasily
14.05.2016
17:37:42
Это не совсем пример кэширования. А "возможность потерять данные" это исключительно вопрос масштаба. Вот допустим есть такая штука, которая работает в 99.9% случаев. пока этот 0.1% не превращается в сотни недовольных пользователей, которые жмут Refresh потому что не видят progress bar - подход вроде как работает. А потом оказывается, что никто не оттестировал случай, когда кэш недоступен, что у ситуации ещё есть 100500 непредусмотренных последствий, т.к. в 99% случаях всё работает и никто не заморачивался на оставшийся 1%
Я согласен - на 1% или на 0.1% случаев есть система которая сама разошлёт письма, смс, позвонит и скажет нежным женским голосом - не все сервисы доступны в данное время, приносим извинения за временные неудобства ;) . Невозможно держать даже самую стабильную систему 100% uptime - иногда бывает форс-мажор. Поэтому всегда есть не технический бекап :) Но на 99% мне нужна система, которая легко ставится, настраивается, мониторится, интегрируется с существующей системой ( читай, есть библиотеки под множество языков ) и имеет более менее человеческий интерфейс ( сказывается моя Виндовая "закалка" ) - отсюда и Каучбейз.

Roman
14.05.2016
19:37:24
https://youtu.be/LXC15K4pV0o?list=PLaFqU3KCWw6KzGwUubZm-9-vKsi6vh5qC #backup #video

16, 17 тема по ссылке

Phil
14.05.2016
19:42:33
проставь сообщению хэштеги

Roman
14.05.2016
19:43:18
какие?

Алексей
14.05.2016
19:49:21
https://youtu.be/LXC15K4pV0o?list=PLaFqU3KCWw6KzGwUubZm-9-vKsi6vh5qC #backup #video
а к этому делу есть текст и тесты какие нить ? для самопроверки понимая

Google
Roman
14.05.2016
19:52:15
У меня нет, но тут есть коллеги из Postgres Professional. Возможно они ответят на твой вопрос.

В конце каждой темы есть практика

Но сделать не всегда означает понять :)

Phil
14.05.2016
19:56:16
какие?
ну а что там? :) по тэгам удобно искать потом в чатике

Roman
14.05.2016
19:57:09
А где ты все теги можно посмотреть, которые уже были?

Roman
14.05.2016
19:57:28
:)

Aleksandr
14.05.2016
19:57:29
не благодарите

Phil
14.05.2016
19:57:56
Roman
14.05.2016
20:00:50
Круто! Добавил #backup

Phil
14.05.2016
20:03:14
и video и tour

Dmitry
15.05.2016
07:42:55
Руслан
15.05.2016
16:36:23
Postgesql+1c+linux Николай, может подскажите адрес чата. Спасибо)

Александр
15.05.2016
16:49:10
А что с 1с, постгрес и линуксом?

Мне тоже интересно, мне тоже скажите

Grisha
15.05.2016
16:57:46
http://m.cnews.ru/news/top/2015-11-05_novyj_rossijskij_linux_obkatyvaetsya_v_armejskih

Alexandr
15.05.2016
19:16:46
Ребят, подскажите пожалуйста, есть какая-то разница между pg_dump и какими-то другими более продвинутыми средствами?

Руслан
15.05.2016
19:22:56
тебе этого чата мало? ?
Тут вроде только о самом pg, без 1с)

Alexey
15.05.2016
19:30:32
выше была ссылка на документ где вроде вполне подробно и понятно описали про логический бэкап

Google
Alexey
15.05.2016
19:30:47
pg_dump это инструмент для логического бэкапа

Denis
16.05.2016
05:41:45
Народ когда результаты на эльбрус будут.... А то не охота выкладывать неофициальные....

Grisha
16.05.2016
05:43:00
А какой именно Эльбрус. Они ж разные...

Denis
16.05.2016
05:45:16
401 402

Конечно желательно 402

С кпи2 и четырмя процами

Grisha
16.05.2016
05:55:54
Там 2 режима. Эмуляция Интел и нативный. Какой интересует?

Denis
16.05.2016
06:02:44
Интересуют реальные результаты..... Конечно в нативном тем более пг есть

Kirill
16.05.2016
06:46:55
про бекапы есть еще вот такое видео https://events.yandex.ru/lib/talks/3202/

Yury
16.05.2016
06:59:13
pg_dump это решение влоб. Если у вас небольшая БД (меньше нескольких гигабайт в архиве) то можете использовать смело и дальше.

Всё остальное как правило когда текущее решение вас не удволетворяет т.е. либо слишком медленно работает либо слишком долго причём долго тут может быть в смысле как бекапа так и востановления.

что то заговорился: первое это слишком много места жрёт.

Dmitry
16.05.2016
07:10:37
что то заговорился: первое это слишком много места жрёт.
Юр, я что-то не понял про что ты? что много места жрет? ты про pitr: pg_basebackup + wal?

Yury
16.05.2016
07:11:20
Alexey
16.05.2016
07:13:57
Я считаю, что в бэкапах место - это вторичное

главное это RTO и RPO

Alexey
16.05.2016
07:14:55
и уж если по бизнесу RPO должно быть малым (минуты, а лучше секунды), то тут никакой логический бэкап через pg_dump или аналогичное вряд ли поможет

Alexey
16.05.2016
07:15:39
а от куда там полная блокировка?

Google
Alexey
16.05.2016
07:16:20
и уж если бизнесу/проекту нужна надежность, то ему нужен человек, который разберется изучит и построит систему резервного копирования

Phil
16.05.2016
07:17:26
а от куда там полная блокировка?
потому что дока говорит, что он SELECT. это или блокировка, или неконсистентность, или я чего-то не понимаю в законах физики

Alexey
16.05.2016
07:18:32
Recovery Point Objective - грубо говоря, сколько данных можно потерять Recovery Time Objective - сколько времени отводится на восстановление в случае сбоя

Vadim
16.05.2016
07:19:24
даже pg_dump консистентный дамп делает, в доке написано ж)

Alexey
16.05.2016
07:19:25
если ты делаешь бэкап через pg_dump каждый день ночью, то в худшем случае ты потеряешь данные за 1 сутки работы решения

для разработчиков и множества вебсайтиков - это нормально

Phil
16.05.2016
07:20:04
MVCC куда дели?
вы тут все сговорились аббривеатурами разговаривать?

Alexey
16.05.2016
07:20:06
бля биллнга или прочих денежных вещей это неприемлемо

фууух

Kirill
16.05.2016
07:21:16
вы тут все сговорились аббривеатурами разговаривать?
постгрес версионик, ему "легко" не лочиться, мин/макс видимости транзакции, все дела )

Phil
16.05.2016
07:21:26
даже pg_dump консистентный дамп делает, в доке написано ж)
значит ему придется блокировать базу. или он делает транзакцию на * и там все это время транзакшн лог какой-нибудь пишется?

Kirill
16.05.2016
07:22:09
http://postgrespro.ru/doc/mvcc.html

Phil
16.05.2016
07:24:02
да я уже понял

Айтуар
16.05.2016
07:24:22
http://www.postgresql.org/docs/9.5/static/app-pgdump.html ключ —serializable-deferrable вроде оно

Phil
16.05.2016
07:26:01
как всгда кстати из доки это сразу не очевидно. может даже есть упоминание (наизусть не помню), но глаз не остановился. ну ок. тогда он просто медленный. и возможно тормозит базу за счет реализации вот этой страшной аббривеатуры. но не факт

Страница 26 из 1062