Извиняюсь за глупый вопрос, но не могли бы вы объяснить, почему у паяльника 5 контактов? Термопара плюс и минус, земля — это понятно. А почему питания нагревателя два? Это один и тот же контакт, просто подогнанный под стандартный разъем, в паяльниках делают по два нагревателя, или как?
Дали таким поработать на выходных. Паяльник супер. Быстро нагревается, легкий, удобно пользоваться. Жало было нормальной длины, не как на фото. Не знаю, покупалось ли отдельно или шло в комплекте.
Статья хорошая. С комментариями выше про Docker и Ansible не соглашусь, я бы лично просто завернул это в виртуалку, притом желательно VirtualBox, потому что он есть у всех.
Очень жаль, что вы про MariaDB забыли, был бы полноценный LEMP стек. Ну и Memcached можно было бы для кучи.
В случае с текстовыми данными нужно учитывать, что в TOAST уже есть LZ-подобное сжатие, поэтому все большие объемы данных и так жмутся. На выравнивании можно выиграть еще 1-2 процента от силы.
Я новичок в электронике. Не могли бы вы объяснить фразу «Частота заполнения 38,4 кГц»? Имеется ввиду, что на принимающей стороне стоит таймер или резонатор с такой частотой и она используется для нарезания сигнала на высокие/низкие уровни или что-то другое?
На счет терминов хочется подчернкнуть, что это не мое личное предложение. Это по мотивам терминологии, используемой в документации Couchbase, Cassandra, Riak, CockroachDB и других СУБД со встроенным шардингом/перебалансировкой.
По поводу прикручивания транзакций сбоку позвольте не согласиться. Прикручиваются, хоть и не без осведомленности приложения или middleware через который приложение ходит в базу http://rystsov.info/2012/09/01/cas.html По-моему там в статье это не подчеркнуто, но чтобы получить настоящий snapshot isolation нужно при чтении ключей делать с ними то же самое, что и при записи. В документации к некоторым СУБД это называют 2PC транзакциями, но мне этот термин не нравится, так как к настоящему 2PC отношения не имеет.
Дисклеймер — написанное ниже очень субъективно и скорее всего придирки. И я понимаю, что целью доклада не являлось осветить это все. Тем не менее.
Во-первых, существует некоторая путаница с терминологией. Каждая СУБД использует немного свои термины, но наиболее общий знаменатель примерно следующий. Под решардингом обычно понимают изменение числа бакетов/vnode. Например, если было hash(key) % 512, решили, что бакетов маловато, и перешли на hash(key) % 1024 или вообще на другую схему. Перенесение бакетов на другие физические машины обычно называют перебалансировкой. Как минимум, было бы не лишним предупредить, что такая путаница вообще есть. Вы же, как я понял, просто для всего решили использовать слово решардинг, тем самым, как мне кажется, оказывая слушателям медвежью услугу.
Во-вторых, немного удивили повороты в стиле что прокси — это SPOF или что во время перебалансировки нода может упасть. Мне кажется само собой разумеющимся, что прокси должен быть не в одном экземпляре, и что «нода» это на самом деле мастер и пара реплик с фейловером (ручным или автоматическим).
Наконец, да, полнота доклада. Что на самом деле интересно слушателям? Как им взять какой-нибудь Redis/Tarantool/PostgreSQL/MySQL/иную-систему-без-встроееного-шардинга и на базе нее построить что-то что масштабируется гаризонтально. Что для этого нужно? Да, действительно, какая-то схема шардирования, какой-то сервис дисковери (как получилось, что не вспомнили хотя бы ZooKeeper, не говоря уже про Consul или etcd? снова оказание медвежьей услуги — ведь слушатели побегут писать свое), процедура решардинга, процедура ребалансировки (важно подчеркнуть, что это отдельные вещи) и, самое интересное, транзакции между нодами.
В сухом остатке. Вы подняли интересную тему, но не дали ответа на вопрос, который действительно всех интересует. Изложение явно не полное. В связи с чем отчасти даже вредное, а не полезное.
Повторюсь, это все субъективная оценка. И я понимаю, что доклад, видимо, был ориентирован на новичков и делался, наверное, давно. Я постараюсь в ближайшем будущем написать свою версию того, как можно решить все описанные проблемы на примере PostgreSQL.
Раньше пробовал разные. Советую посмотреть на DataGrip от JetBrains.
Не подскажете книгу или несколько хороших книг по этой теме?
Извиняюсь за глупый вопрос, но не могли бы вы объяснить, почему у паяльника 5 контактов? Термопара плюс и минус, земля — это понятно. А почему питания нагревателя два? Это один и тот же контакт, просто подогнанный под стандартный разъем, в паяльниках делают по два нагревателя, или как?
Очень жаль, что вы про MariaDB забыли, был бы полноценный LEMP стек. Ну и Memcached можно было бы для кучи.
В случае с текстовыми данными нужно учитывать, что в TOAST уже есть LZ-подобное сжатие, поэтому все большие объемы данных и так жмутся. На выравнивании можно выиграть еще 1-2 процента от силы.
Я новичок в электронике. Не могли бы вы объяснить фразу «Частота заполнения 38,4 кГц»? Имеется ввиду, что на принимающей стороне стоит таймер или резонатор с такой частотой и она используется для нарезания сигнала на высокие/низкие уровни или что-то другое?
По поводу прикручивания транзакций сбоку позвольте не согласиться. Прикручиваются, хоть и не без осведомленности приложения или middleware через который приложение ходит в базу http://rystsov.info/2012/09/01/cas.html По-моему там в статье это не подчеркнуто, но чтобы получить настоящий snapshot isolation нужно при чтении ключей делать с ними то же самое, что и при записи. В документации к некоторым СУБД это называют 2PC транзакциями, но мне этот термин не нравится, так как к настоящему 2PC отношения не имеет.
Во-первых, существует некоторая путаница с терминологией. Каждая СУБД использует немного свои термины, но наиболее общий знаменатель примерно следующий. Под решардингом обычно понимают изменение числа бакетов/vnode. Например, если было hash(key) % 512, решили, что бакетов маловато, и перешли на hash(key) % 1024 или вообще на другую схему. Перенесение бакетов на другие физические машины обычно называют перебалансировкой. Как минимум, было бы не лишним предупредить, что такая путаница вообще есть. Вы же, как я понял, просто для всего решили использовать слово решардинг, тем самым, как мне кажется, оказывая слушателям медвежью услугу.
Во-вторых, немного удивили повороты в стиле что прокси — это SPOF или что во время перебалансировки нода может упасть. Мне кажется само собой разумеющимся, что прокси должен быть не в одном экземпляре, и что «нода» это на самом деле мастер и пара реплик с фейловером (ручным или автоматическим).
Наконец, да, полнота доклада. Что на самом деле интересно слушателям? Как им взять какой-нибудь Redis/Tarantool/PostgreSQL/MySQL/иную-систему-без-встроееного-шардинга и на базе нее построить что-то что масштабируется гаризонтально. Что для этого нужно? Да, действительно, какая-то схема шардирования, какой-то сервис дисковери (как получилось, что не вспомнили хотя бы ZooKeeper, не говоря уже про Consul или etcd? снова оказание медвежьей услуги — ведь слушатели побегут писать свое), процедура решардинга, процедура ребалансировки (важно подчеркнуть, что это отдельные вещи) и, самое интересное, транзакции между нодами.
В сухом остатке. Вы подняли интересную тему, но не дали ответа на вопрос, который действительно всех интересует. Изложение явно не полное. В связи с чем отчасти даже вредное, а не полезное.
Повторюсь, это все субъективная оценка. И я понимаю, что доклад, видимо, был ориентирован на новичков и делался, наверное, давно. Я постараюсь в ближайшем будущем написать свою версию того, как можно решить все описанные проблемы на примере PostgreSQL.