Re[9]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.19 13:35
Оценка: 107 (6) +1
Здравствуйте, Sharov, Вы писали:

S>Она и не должна отвечать на ентот вопрос. Она отвечает за состояние всей системы целиком, а не отдельных компонентов. Вопрос выше -- вопрос на тему избыточности компонентов, репликации.

S>Т.е. типа диск ломается раз в три года, у нас 1000 дисков, и следовательно десятки дисков будут ломаться ежедневно. Ну и т.д. Причем здесь CAP&
Охохохо. Начнём с азов: что такое availability? Вот у нас есть запрос клиента, вот есть на него ответ. То есть availability — это способность системы отвечать на запросы, так?
Но ведь ответы никогда не приходят мгновенно!
Предположим, у нас случилось нарушение коммуникации между клиентом и сервером (в современном интернете это происходит сплошь и рядом). Это нарушение исправили через 10 секунд.
Ответ получен? Получен. Система доступна? Доступна.
Ок, починка заняла неделю. Ничто не мешает нам реализовать коммуникационный слой таким образом, чтобы это выглядело не как отказ, а как медленный ответ.
Ну, тогда у нас вообще никаких проблем с availability не бывает никогда — рано или поздно система таки ответит.
Ой, а как же CAP? А вот так: нет никакого CAP, если разрешить unbounded delays.
А если запретить? То есть у нас ответ на запрос должен приходить за время T0. Отсутствие ответа = сбой.
Ну ок, мы понимаем, что даже безо всякого Partition и Consistency есть шанс не получить ответ — много что может случиться, так ведь?
Значит, мы выражаем Availability в виде приемлемого % запросов, которые вылезут за пределы T0.
И нас может устраивать availability в 90, 99, 99.9, 99.99% и так далее. И таймаут может быть 5мс, 5с, или 50с. .
Понятно, что от выбора этих требований зависит сложность их обеспечить — например, если у нас частота сбоев внутрисистемной коммуникации ниже определённой, или, скажем, время их разрешения быстрее определённого, то мы запросто можем получить нужную нам availability без потери consistency, несмотря на наличие partition.

Точно так же и consistency — есть много разных вариантов трактовки этого требования, есть более жёсткие и менее жёсткие требования; и не факт, что в нашей прикладной задаче прямо необходимо будет требовать выполнения произвольных предикатов над полными разделяемыми данными.

Полезной была бы теорема вроде Шеннона, которая бы связывала количественные метрики — сколько процентов availability можно получить из M узлов, если availability каждого узла X, а availability связывающей их сети — Y.
CAP бесконечно далека от этого, увы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: DB internals, книги/блоги и т.п.
От: JacobR  
Дата: 13.08.19 10:40
Оценка: 47 (5) +1
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.

KP>В принципе, если я не ошибаюсь, то описание архитектуры Berkeley DB можно найти в "Architecture of open source applications", что тоже хорошо, но вот хотелось бы про PostgreSQL или MySQL. Можно книгу, можно набор заметок в блоге. Что угодно, короче

Для ответа на собеседовании хорошая статья http://coding-geek.com/how-databases-work/

ну и классика Database Systems The Complete Book

https://www.amazon.com/Database-Systems-Complete-Book-Garcia-Molina/dp/933251867X/ref=sr_1_2?keywords=Database+Systems.+The+Complete+Book&qid=1565692427&s=gateway&sr=8-2

тут есть все, реляционная алгебра, кэши, B-деревья, транзакции, оптимизация и пр.
Re[5]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.19 03:57
Оценка: 62 (4)
Здравствуйте, Sharov, Вы писали:
S>До ентого не дошел пока, а что с CAP может быть не так? Единственная мало-мальски адекватная (формальная???) модель для распеределенных приложений. Этакая теорема Шеннона для распределенных систем.
1. Во-первых, она криво сформулирована. Поскольку нет такого понятия, как Partition Tolerance в отдельности от Consistency, не имеет и смысл ставить вопрос так, как будто там есть выбор. Более корректная, но менее красивая формулировка утверждения этой теоремы состоит в том, что при network partition вам придётся выбирать между consistency и availability.
2. Во-вторых, она бесполезна, т.к. не предлагает никаких инструментов для управления этим выбором. Грубо говоря, могу ли я частично пожертовать availability, чтобы получить частичную consistency? Если да, то насколько? Если нет, то почему?

The Unhelpful CAP Theorem

CAP is sometimes presented as Consistency, Availability, Partition tolerance: pick 2
out of 3. Unfortunately, putting it this way is misleading [32] because network partitions
are a kind of fault, so they aren’t something about which you have a choice: they
will happen whether you like it or not [38].
At times when the network is working correctly, a system can provide both consistency
(linearizability) and total availability. When a network fault occurs, you have to
choose between either linearizability or total availability. Thus, a better way of phrasing
CAP would be either Consistent or Available when Partitioned [39]. A more reliable
network needs to make this choice less often, but at some point the choice is
inevitable.
In discussions of CAP there are several contradictory definitions of the term availability,
and the formalization as a theorem [30] does not match its usual meaning [40].
Many so-called “highly available” (fault-tolerant) systems actually do not meet CAP’s
idiosyncratic definition of availability. All in all, there is a lot of misunderstanding
and confusion around CAP, and it does not help us understand systems better, so
CAP is best avoided.

(Martin Kleppman, DDIA)
См. тж. https://arxiv.org/abs/1509.05393
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Отредактировано 14.08.2019 4:02 Sinclair . Предыдущая версия .
Re[11]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.08.19 01:54
Оценка: 51 (3)
Здравствуйте, Sharov, Вы писали:

S>В DDIA вообще ничего не вводится. Болтовня, немного обо всем. Если бы DDIA ввела бы понятия CAP в 2000 году, тогда да, согласен. Для 2019 это набор ссылок в конце глав, неплохой.

S>CAP -- это набор ключевых понятий, которых не было и оне вдруг сформулировались. Стало понятно куда копать и над чем думать\работать. Енто уже большое дело!
А можно уточнить — какие именно "ключевые понятия" введены в CAP?

S>Просто никто следущий шаг, количественный, не сделал или его просто невозможно сделать? Или он у каждой системы свой... Может мы не знаем, а оне есть?...

Почему не сделал? Сделал. Липтон и Сандберг, к примеру, доказали, что any algorithm implementing a sequentially consistent read-write registermust have|r|+|w| ≥d, where |r| is the latency of a read operation, |w| is the latency of a write operation,and d is the network delay. Это как бы 1988. Аттия и Уэлч в 1995 доказывают, что any algorithm implementing a linearizable read-write register must have an operation latency of at least u/2, where u is the uncertainty of delay in the network between replicas.

Это к вопросу о том, что до CAP "никто не занимался распределёнными системами", ага.

S>>Вот потому-то CAP лучше забыть, как страшный сон, и начать читать нормальную литературу.


S>Пример нормальной литературы можно, кроме работ Лэмпорта? Оне вообще есть. DDIA не предлагать, это не учебная литература, а обзорная. Танненбаум?

Начать можно отсюда: https://arxiv.org/pdf/1509.05393.pdf.

S>Это, вероятно, работа Лэмпорта и есть, еще годов 70-х.

Нет, Лэмпорт в нашем ВЦ совершенно точно не работал.

S>Благодаря CAP состоялась не одна система, которой, вероятно, мы пользуемся каждый день. Огромному число архитекторов сэкномили время на изобретения велосипедов и решения несущственных проблем,

S>четко указав чем мы жертвуем в том или ином случае. Польза есть и немалая.
Чего? Какие системы "состоялись благодаря CAP"? Вы, коллега, что-то путаете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: DB internals, книги/блоги и т.п.
От: Stalker. Австралия  
Дата: 14.08.19 06:26
Оценка: +3
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.

KP>В принципе, если я не ошибаюсь, то описание архитектуры Berkeley DB можно найти в "Architecture of open source applications", что тоже хорошо, но вот хотелось бы про PostgreSQL или MySQL. Можно книгу, можно набор заметок в блоге. Что угодно, короче

странно что Кalen Delaney никто не упомянул, ее набор книг по внутреннястям сервера абсолютная классика
Re[9]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.19 14:01
Оценка: 69 (2)
Здравствуйте, Sharov, Вы писали:

S>Не согласен. Енто уже некий словарь ключевых теримнов и понятий, от которых можно оттолкнуться и вокруг которых можно строить разговор, архитектуру.

Ну конечно же нет. Словарь ключевых терминов и понятий вводится как раз, к примеру, в DDIA. Или в той же статье Клеппмана, на которую я тут сослался.
S>Аналогом К-Ш было введение понятия частоты, дискретизации, желание воспроизвести сигнал и т.д. Базовые вещи и понятия. Далее идет сама т. К-Ш, количественная.
Ну так она количественная как раз потому, что у нас в базовых понятиях есть количественные показатели. А если бы мы, как в CAP, оперировали абсолютностями, вроде "сигнал" и "идеально восстановить сигнал", то никакой К-Ш сформулировать бы не удалось. Потому что в CAP нет ни малейшего желания availability измерять в каких-то единицах, кроме "есть"/"нету".

S>И тут в мире распр. систем наступает затык. Вот допустим я хочу построить систему, где у меня будет

S>< 100 req/sec. я должен ..., а если >100000 req/sec. я должен... Т.е. количества у нас нет, нету математики формул и т.д. Но хотя бы есть ключевые понятия (CAP).
Ну естественно. С таким базисом, как CAP, двигаться некуда — сразу затык. Если availability (или consistency) нету, то о чём дальше говорить? Всё, темнота, хаос. Нет никаких параметров, формулы для которых мы бы могли придумать.
Типа если у нас наступил P, и мы не готовы жертвовать Consistency, то всё, никакой тебе A. Никакие реквесты, даже частично, даже за длинное время, невыполнимы.
Или наоборот — если мы хотим A, то при наступлении P мы можем вообще на любой запрос отдавать 42 — а чо, consistency же нет!
Нельзя, к примеру, давать оплачивать никакие покупки, даже на сумму менее 100р, при отсутствии двусторонней связи с банком-эмитентом — АВДРУГ!
А ведь если мы понятие consistency задаём как "нельзя снять со счёта в минус", то при наступлении P сегмент размера S может безопасно разрешить списание вплоть до S/STotal от суммы счёта на момент разделения.
Ухты, как же так? Ведь CAP нам явно запрещает получать одновременно C и A? А вот так. При последующем слиянии сегментов транзакции прекрасно отсериализуются, без нарушения инвариантов.
Вот потому-то CAP лучше забыть, как страшный сон, и начать читать нормальную литературу.

S>>>Имеем распределенные системы, дано -- ограниченный по своим ресурсам

S>>>компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP.
S>>Ну это, конечно же, неправда.

S>Кроме Лэмпорта что-то еще было?

Да кто угодно этим занимался. Я лично читал локальные публикации про распределённые системы ещё в 90х. Что-то типа "концепция времени в распределённых системах".
Но это неважно — даже если бы вообще никаких других результатов не было вплоть до послезавтра, ценность у CAP отрицательная. Именнно потому, что она провоцирует на неверные выводы — хуже, чем Проблема Останова.
S>Полностью согласен, но CAP выбрасыать не стоит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: DB internals, книги/блоги и т.п.
От: BlackEric http://black-eric.lj.ru
Дата: 13.08.19 07:39
Оценка: 18 (1) +1
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.

KP>В принципе, если я не ошибаюсь, то описание архитектуры Berkeley DB можно найти в "Architecture of open source applications", что тоже хорошо, но вот хотелось бы про PostgreSQL или MySQL. Можно книгу, можно набор заметок в блоге. Что угодно, короче

Подобное описание ни разу не попадалось. Сам бы почитал с интересом.
По PostgreSQL есть серия статей: MVCC-1. Изоляция и далее от этого автора. Но это далеко не полное изложение вопроса.
https://github.com/BlackEric001
Re: DB internals, книги/блоги и т.п.
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 13.08.19 12:46
Оценка: 18 (2)
Здравствуйте, kaa.python, Вы писали:

Я вот ещё на что набрёл, читаю. Очень интересно и в принципе похоже на то, что я искал: http://www.interdb.jp/pg/index.html
Re[7]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.19 07:49
Оценка: 7 (1) +1
Здравствуйте, kaa.python, Вы писали:
S>>2. Во-вторых, она бесполезна, т.к. не предлагает никаких инструментов для управления этим выбором.
KP>Так она и не должна отвечать на этот вопрос. Ведь суть теоремы не в том что бы дать решение, а в том, что бы обозначить границы возможностей.
Если честно, суть этой теоремы — в красивой аббревиатуре, чтобы похайпиться. Для сравнения посмотрите на принцип неопределённости Гейзенберга — помимо очевидной констатации того, что "невозможно одновременно измерить коммутирующие величины", там есть и строгая количественная метрика этой "невозможности"
S>>Грубо говоря, могу ли я частично пожертовать availability, чтобы получить частичную consistency? Если да, то насколько? Если нет, то почему?
KP>По мне так она как раз и дает ответ на твой вопрос, так как ты требуешь только одну гарантию P и согласен пожертвовать A и С, что как раз не противоречит теореме.
Нет. Во-первых, я ничего не "требую". Несмотря на формулировку теоремы, невозможно выбрать сочетание A и C, "отказавшись" от P.
Во-вторых, меня интересует не "пожертвовать A и С", а принимать инженерные решения. В инженерном подходе бессмысленно говорить об Availability как о бинарном параметре — да и вообще почти все параметры описываются гораздо более сложными моделями, чем есть/нету. Я и так понимаю, что даже безо всяких CAP невозможно получить гарантированную availability, даже пожертвовав вообще всем — потому что превращение Солнца в сверхновую гарантированно уничтожит мою систему, даже если я сделаю резервную реплику на Юпитере. Меня интересует, как достичь заданного заказчиком процента отказов, при условии, что я знаю профили отказов компонентов, из которых я строю свою систему.
На этот вопрос теорема не только не отвечает, но даже и не пытается.
Поэтому её ценность ничуть не выше, чем народные мудрости вроде "сколько веревочка ни вейся, всё равно конец будет".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: DB internals, книги/блоги и т.п.
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 13.08.19 15:06
Оценка: :))
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился ...


"... завыл матерно, напился, набил морду вопрошавшему, долго бился головой об стенку — в общем, ушел от ответа" (с) Жванецкий
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[6]: CAP
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 14.08.19 04:41
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>2. Во-вторых, она бесполезна, т.к. не предлагает никаких инструментов для управления этим выбором.

Так она и не должна отвечать на этот вопрос. Ведь суть теоремы не в том что бы дать решение, а в том, что бы обозначить границы возможностей.

S>Грубо говоря, могу ли я частично пожертовать availability, чтобы получить частичную consistency? Если да, то насколько? Если нет, то почему?


По мне так она как раз и дает ответ на твой вопрос, так как ты требуешь только одну гарантию P и согласен пожертвовать A и С, что как раз не противоречит теореме.
Re[9]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.19 09:15
Оценка: -2
Здравствуйте, kaa.python, Вы писали:
KP>Почему это? Можно, просто ты получаешь, к примеру при наличии системы из двух узлов, две независимые системы которые удовлетворяют A и C, и, что интересно, P тоже, так как подобная система рано или поздно вырождается в набор независимых узлов.
В этой трактовке непонятно, что такое Consistency. Если нас устраивает ситуация, в которой две независимые системы имеют разные представления об истинности каких-то утверждений, то вообще непонятно, зачем мы изначально их склеивали в одну систему. Понятно, что M независимых систем гораздо надёжнее и проще устроены, чем одна композитная система с M компонентами.

S>>Во-вторых, меня интересует не "пожертвовать A и С", а принимать инженерные решения. В инженерном подходе бессмысленно говорить об Availability как о бинарном параметре — да и вообще почти все параметры описываются гораздо более сложными моделями, чем есть/нету. Я и так понимаю, что даже безо всяких CAP невозможно получить гарантированную availability, даже пожертвовав вообще всем — потому что превращение Солнца в сверхновую гарантированно уничтожит мою систему, даже если я сделаю резервную реплику на Юпитере. Меня интересует, как достичь заданного заказчиком процента отказов, при условии, что я знаю профили отказов компонентов, из которых я строю свою систему.


KP>По моему мнению, теорема не должна в принципе давать ответа на такой вопрос, так как она как раз и описывает набор бинарных свойств.

Хорошая теорема — должна.
KP>Тут скорее дело в том, что у разных людей разные ожидания от теоремы как таковой. Лично мне она было очень полезна на начальном этапе, так как дает базовую, бинарную логику. А потом уже приходит понимание того, о чем ты пишешь выше.
Я всё же рекомендую внимательно ознакомиться со статьёй Клеппана на эту тему. Сейчас теорема CAP интересна не более, чем представления древних греков о структуре материи с точки зрения современной физики.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: DB internals, книги/блоги и т.п.
От: Sharov Россия  
Дата: 13.08.19 14:38
Оценка: 68 (1)
Здравствуйте, Sinclair, Вы писали:

S>А недавно (~2 месяца тому) я внезапно обнаружил, что мимо меня прошла настолько широкоизвестная книга, что на неё в дискуссиях ссылаются аббревиатурой — DDIA.

S>Там, к сожалению, мало про internals, зато хорошо рассказано про принципы построения современных систем. Глубина изложения там не такая, как у Гарсиа-Молина, зато широта охвата потрясающая, и огромный (огромный!) список литературы. Подозреваю, что можно запросто потратить год-полтора, просто проходя по ссылкам в конце каждой главы.

Читаю ее сильно в фоновом режиме. Она оченно поверхостна, т.е. досматриваю ссылки или ютуб для большего углубления. Но кругозор дает, енто да. Про бд там вроде совсем чуть-чуть, что-то типа LSM vs B-tree + ACID.
Пока не очень.
Кодом людям нужно помогать!
Re: DB internals, книги/блоги и т.п.
От: m2l  
Дата: 13.08.19 08:09
Оценка: 9 (1)
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.

Действительно бесценны, поскольку для PostgreSQL единственное внятное описание внутренней работы это именно её исходники.
Если не читал, попробуй Тома Кайта, Oracle для профессионалов и папку Documentation которая идёт с дистрибутивом Oracle. В чистом виде внутреннее устройство там описывается в общих чертах, довольно поверхностно. Но исходя из этого описания можно получить представления что и как сделано. И скорей всего ознакомление с этим базисом поможет тебе понимать исходники PostgreSQL.
Re[2]: DB internals, книги/блоги и т.п.
От: TMU_1  
Дата: 13.08.19 10:19
Оценка: 9 (1)
m2l>Действительно бесценны, поскольку для PostgreSQL единственное внятное описание внутренней работы это именно её исходники.
m2l>Если не читал, попробуй Тома Кайта, Oracle для профессионалов и папку Documentation которая идёт с дистрибутивом Oracle.


Oracle Core: Essential Internals for DBAs and Developers
Authors: Lewis, Jonathan

Можно еще вот эту книжечку посмотреть.
Re: DB internals, книги/блоги и т.п.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.08.19 14:21
Оценка: 9 (1)
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.

KP>В принципе, если я не ошибаюсь, то описание архитектуры Berkeley DB можно найти в "Architecture of open source applications", что тоже хорошо, но вот хотелось бы про PostgreSQL или MySQL. Можно книгу, можно набор заметок в блоге. Что угодно, короче
Гарсиа-Молина уже посоветовали. Она мне прямо открыла свет волшебной лампы в своё время.
А недавно (~2 месяца тому) я внезапно обнаружил, что мимо меня прошла настолько широкоизвестная книга, что на неё в дискуссиях ссылаются аббревиатурой — DDIA.
Там, к сожалению, мало про internals, зато хорошо рассказано про принципы построения современных систем. Глубина изложения там не такая, как у Гарсиа-Молина, зато широта охвата потрясающая, и огромный (огромный!) список литературы. Подозреваю, что можно запросто потратить год-полтора, просто проходя по ссылкам в конце каждой главы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.19 13:24
Оценка: 7 (1)
Здравствуйте, Sharov, Вы писали:

S>Она ни в коем случае не бесполезна, т.к. является формализмом и точкой отправления для рассуждений об распр. системах. Выше я привел ссылку на теорему Шеннона из которой и других подобных теорем выработан подробный мат. аппарат и целая теория (теория информации), как из шумящих и ненадежных по отдельности систем за счет математики и прочих формализмов сделать систему надежную.

Прекрасная аналогия. Теорема Шеннона имеет количественную формулировку. Аналогом CAP для Котельникова-Шеннона было бы утверждение вроде "обеспечение бесконечной точности воспроизведения сигнала требует бесконечной частоты дискретизации". Ну, как бы да, ичо? Во-первых, это очевидно, во-вторых, это бесполезно.

S>Имеем распределенные системы, дано -- ограниченный по своим ресурсам

S>компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP.
Ну это, конечно же, неправда.
S>Нету какой-то систематизированной теории распределенных систем, все пишут в меру своего понимания. Выше пример, как каждый по-своему понимает тот же CAP. Про теоремы вообще молчу. Понятоно, что есть Лесил Лампорт со своими работами по консенсусу в распределенных системах, аналог Клода Шеннона в ти. Но как-то ентого кажется не достаточно, кмк. Т.е. мне видится разработка распр. как искусство,
S>нежели инженерное ремесло.
Это как раз очень плохо, т.к. в данном контексте термин "искусство" — ругательный. И я вижу, как систематизированная теория распределённых систем всё же строится. И для её построения нужно избегать мусора типа CAP, а заниматься нормальными инженерными расчётами и математическими обоснованиями.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: DB internals, книги/блоги и т.п.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.08.19 15:24
Оценка: 6 (1)
Здравствуйте, Sharov, Вы писали:


S>Читаю ее сильно в фоновом режиме. Она оченно поверхостна, т.е. досматриваю ссылки или ютуб для большего углубления. Но кругозор дает, енто да. Про бд там вроде совсем чуть-чуть, что-то типа LSM vs B-tree + ACID.

S>Пока не очень.
Ну, на мой вкус она крайне удачно дополняет Гарсиа-Молина, в которой очень хорошо описаны подробности реализации RDBMS, но почти ничего про то, что случилось с DB-миром после 1995 там нет.
DDIA крайне удачно задаёт "координаты измерений", и потряает меня неожиданной корректностью в тонких местах — вроде отсутствия честного serializable в Oracle и некорректности/бесполезности CAP-теоремы.
Насколько я понимаю, книг уровня Гарсиа-Молина для NoSQL в природе не существует — зато есть большое количество статей, которые как описывают теорию, так и закапываются в детали конкретных реализаций. И вот как раз они-то доступны по ссылкам из книги.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: DB internals, книги/блоги и т.п.
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.08.19 13:03
Оценка: 3 (1)
Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, JacobR, Вы писали:


JR>>Для ответа на собеседовании хорошая статья http://coding-geek.com/how-databases-work/


BE>Реально классно. Её бы на русский перевести.

Первая редакция (https://www.amazon.com/Database-Systems-Complete-Book-GOAL/dp/0130319953/ref=pd_sbs_14_2/136-3378542-8630840?_encoding=UTF8&amp;pd_rd_i=0130319953&amp;pd_rd_r=7b8d3a72-c26d-4e1f-b1f7-2cd1f9cedb9b&amp;pd_rd_w=WFuCA&amp;pd_rd_wg=NeY7z&amp;pf_rd_p=1c11b7ff-9ffb-4ba6-8036-be1b0afa79bb&amp;pf_rd_r=VV2G6EWTRRAXWG8TD0Z7&amp;psc=1&amp;refRID=VV2G6EWTRRAXWG8TD0Z7) выходила на русском:
https://www.ozon.ru/context/detail/id/1351096/
Автор(ы): Гектор Гарсиа-Молина, Джеффри Ульман, Дженнифер Уидом
Издательство: Вильямс
Цена: 424р.

Книга известного специалиста в области компьютерных наук Дж.Ульмана и его именитых коллег по Станфордскому университету является уникальным учебным и справочным пособием, которое отличается беспрецедентными широтой и глубиной охвата предмета и
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: CAP
От: Sharov Россия  
Дата: 13.08.19 15:42
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>DDIA крайне удачно задаёт "координаты измерений", и потряает меня неожиданной корректностью в тонких местах — вроде отсутствия честного serializable в Oracle и некорректности/бесполезности CAP-теоремы.


До ентого не дошел пока, а что с CAP может быть не так? Единственная мало-мальски адекватная (формальная???) модель для распеределенных приложений. Этакая теорема Шеннона для распределенных систем.
Кодом людям нужно помогать!
Re[8]: CAP
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 14.08.19 08:29
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Нет. Во-первых, я ничего не "требую". Несмотря на формулировку теоремы, невозможно выбрать сочетание A и C, "отказавшись" от P.


Почему это? Можно, просто ты получаешь, к примеру при наличии системы из двух узлов, две независимые системы которые удовлетворяют A и C, и, что интересно, P тоже, так как подобная система рано или поздно вырождается в набор независимых узлов.

S>Во-вторых, меня интересует не "пожертвовать A и С", а принимать инженерные решения. В инженерном подходе бессмысленно говорить об Availability как о бинарном параметре — да и вообще почти все параметры описываются гораздо более сложными моделями, чем есть/нету. Я и так понимаю, что даже безо всяких CAP невозможно получить гарантированную availability, даже пожертвовав вообще всем — потому что превращение Солнца в сверхновую гарантированно уничтожит мою систему, даже если я сделаю резервную реплику на Юпитере. Меня интересует, как достичь заданного заказчиком процента отказов, при условии, что я знаю профили отказов компонентов, из которых я строю свою систему.


По моему мнению, теорема не должна в принципе давать ответа на такой вопрос, так как она как раз и описывает набор бинарных свойств. Тут скорее дело в том, что у разных людей разные ожидания от теоремы как таковой. Лично мне она было очень полезна на начальном этапе, так как дает базовую, бинарную логику. А потом уже приходит понимание того, о чем ты пишешь выше.
Re[6]: CAP
От: Sharov Россия  
Дата: 14.08.19 10:46
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>1. Во-первых, она криво сформулирована. Поскольку нет такого понятия, как Partition Tolerance в отдельности от Consistency, не имеет и смысл ставить вопрос так, как будто там есть выбор. Более корректная, но менее красивая формулировка утверждения этой теоремы состоит в том, что при network partition вам придётся выбирать между consistency и availability.

S>2. Во-вторых, она бесполезна, т.к. не предлагает никаких инструментов для управления этим выбором. Грубо говоря, могу ли я частично пожертовать availability, чтобы получить частичную consistency? Если да, то насколько? Если нет, то почему?


Она ни в коем случае не бесполезна, т.к. является формализмом и точкой отправления для рассуждений об распр. системах. Выше я привел ссылку на теорему Шеннона из которой и других подобных теорем выработан подробный мат. аппарат и целая теория (теория информации), как из шумящих и ненадежных по отдельности систем за счет математики и прочих формализмов сделать систему надежную. Имеем распределенные системы, дано -- ограниченный по своим ресурсам
компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP. Нету какой-то систематизированной теории распределенных систем, все пишут в меру своего понимания. Выше пример, как каждый по-своему понимает тот же CAP. Про теоремы вообще молчу. Понятоно, что есть Лесил Лампорт со своими работами по консенсусу в распределенных системах, аналог Клода Шеннона в ти. Но как-то ентого кажется не достаточно, кмк. Т.е. мне видится разработка распр. как искусство,
нежели инженерное ремесло.
Кодом людям нужно помогать!
Re[10]: CAP
От: chaotic-kotik  
Дата: 14.08.19 10:59
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Я всё же рекомендую внимательно ознакомиться со статьёй Клеппана на эту тему. Сейчас теорема CAP интересна не более, чем представления древних греков о структуре материи с точки зрения современной физики.


Ты как-то криво это прочитал и преувеличиваешь. САР описывает регистр, она не описывает базу данных. В базе данных у тебя может быть свой отдельный трейдоф для чтения/записи/разных уровней изоляции.
Re[8]: CAP
От: Sharov Россия  
Дата: 14.08.19 11:00
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S> Меня интересует, как достичь заданного заказчиком процента отказов, при условии, что я знаю профили отказов компонентов, из которых я строю свою систему.


Она и не должна отвечать на ентот вопрос. Она отвечает за состояние всей системы целиком, а не отдельных компонентов. Вопрос выше -- вопрос на тему избыточности компонентов, репликации.
Т.е. типа диск ломается раз в три года, у нас 1000 дисков, и следовательно десятки дисков будут ломаться ежедневно. Ну и т.д. Причем здесь CAP&
Кодом людям нужно помогать!
Re[10]: CAP
От: Sharov Россия  
Дата: 14.08.19 15:16
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>>Не согласен. Енто уже некий словарь ключевых теримнов и понятий, от которых можно оттолкнуться и вокруг которых можно строить разговор, архитектуру.

S>Ну конечно же нет. Словарь ключевых терминов и понятий вводится как раз, к примеру, в DDIA. Или в той же статье Клеппмана, на которую я тут сослался.

В DDIA вообще ничего не вводится. Болтовня, немного обо всем. Если бы DDIA ввела бы понятия CAP в 2000 году, тогда да, согласен. Для 2019 это набор ссылок в конце глав, неплохой.
CAP -- это набор ключевых понятий, которых не было и оне вдруг сформулировались. Стало понятно куда копать и над чем думать\работать. Енто уже большое дело!

S>>Аналогом К-Ш было введение понятия частоты, дискретизации, желание воспроизвести сигнал и т.д. Базовые вещи и понятия. Далее идет сама т. К-Ш, количественная.

S>Ну так она количественная как раз потому, что у нас в базовых понятиях есть количественные показатели. А если бы мы, как в CAP, оперировали абсолютностями, вроде "сигнал" и "идеально восстановить сигнал", то никакой К-Ш сформулировать бы не удалось. Потому что в CAP нет ни малейшего желания availability измерять в каких-то единицах, кроме "есть"/"нету".

Просто никто следущий шаг, количественный, не сделал или его просто невозможно сделать? Или он у каждой системы свой... Может мы не знаем, а оне есть?...

S>Вот потому-то CAP лучше забыть, как страшный сон, и начать читать нормальную литературу.


Пример нормальной литературы можно, кроме работ Лэмпорта? Оне вообще есть. DDIA не предлагать, это не учебная литература, а обзорная. Танненбаум?


S>>Кроме Лэмпорта что-то еще было?

S>Да кто угодно этим занимался. Я лично читал локальные публикации про распределённые системы ещё в 90х. Что-то типа "концепция времени в распределённых системах".

Это, вероятно, работа Лэмпорта и есть, еще годов 70-х.

S>Но это неважно — даже если бы вообще никаких других результатов не было вплоть до послезавтра, ценность у CAP отрицательная. Именнно потому, что она провоцирует на неверные выводы — хуже, чем Проблема Останова.


Благодаря CAP состоялась не одна система, которой, вероятно, мы пользуемся каждый день. Огромному число архитекторов сэкномили время на изобретения велосипедов и решения несущственных проблем,
четко указав чем мы жертвуем в том или ином случае. Польза есть и немалая.

Позже запилю с ссылкой енту дискуссию в пост для широкой аудитории. Вопрос интересный. Либо выделить енту подветку во flame.comp, отредактировав заголовок типа "Теория инф-ии vs распеделенные системы".
Кодом людям нужно помогать!
Отредактировано 14.08.2019 16:46 Sharov . Предыдущая версия .
Re[2]: DB internals, книги/блоги и т.п.
От: BlackEric http://black-eric.lj.ru
Дата: 09.02.20 20:12
Оценка: +1
Здравствуйте, JacobR, Вы писали:

JR>Для ответа на собеседовании хорошая статья http://coding-geek.com/how-databases-work/


Перевел начало на русский: Как работают реляционные базы данных (Часть 1)
https://github.com/BlackEric001
DB internals, книги/блоги и т.п.
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 13.08.19 05:25
Оценка:
На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.
В принципе, если я не ошибаюсь, то описание архитектуры Berkeley DB можно найти в "Architecture of open source applications", что тоже хорошо, но вот хотелось бы про PostgreSQL или MySQL. Можно книгу, можно набор заметок в блоге. Что угодно, короче
Re[2]: DB internals, книги/блоги и т.п.
От: BlackEric http://black-eric.lj.ru
Дата: 13.08.19 12:02
Оценка:
Здравствуйте, JacobR, Вы писали:

JR>Для ответа на собеседовании хорошая статья http://coding-geek.com/how-databases-work/


Реально классно. Её бы на русский перевести.
https://github.com/BlackEric001
Re: DB internals, книги/блоги и т.п.
От: Sazon  
Дата: 13.08.19 15:19
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.

KP>В принципе, если я не ошибаюсь, то описание архитектуры Berkeley DB можно найти в "Architecture of open source applications", что тоже хорошо, но вот хотелось бы про PostgreSQL или MySQL. Можно книгу, можно набор заметок в блоге. Что угодно, короче

У mail.ru есть видео-лекции касаемо БД (техносфера, К.Осипов): B-деревья, LSM, кэширование, WAL, работа планировщика транзакций, 2PL и т.д.
Re: DB internals, книги/блоги и т.п.
От: chaotic-kotik  
Дата: 14.08.19 07:45
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>На одном из собеседований мне задали достаточно занятный вопрос "А знаю ли я как работают базы данных внутри на примере любого движка?". Честно говоря, я слился так как расписать, пусть и условно, что происходит от начала формирования запроса до того как данные попадут на диск у меня фантазии не хватает. Но так как вопрос был, надо признать, довольно интересный и разумный, мне стало интересно что-то на этот счет почитать. Можете что-то посоветовать на этот счет? Я бы предпочел по PostgreSQL или MySQL, так как ссылки на исходники бесценны.

KP>В принципе, если я не ошибаюсь, то описание архитектуры Berkeley DB можно найти в "Architecture of open source applications", что тоже хорошо, но вот хотелось бы про PostgreSQL или MySQL. Можно книгу, можно набор заметок в блоге. Что угодно, короче

Database Internals, Alex Popov
книга не вышла еще правда, но на портале O'Reily можно уже прочитать

Есть еще видео лекции Andy Pavlo — CMU Database Systems и CMU Advanced Database Systems.
Re[8]: CAP
От: Sharov Россия  
Дата: 14.08.19 13:42
Оценка:
Здравствуйте, Sinclair, Вы писали:


S>Прекрасная аналогия. Теорема Шеннона имеет количественную формулировку. Аналогом CAP для Котельникова-Шеннона было бы утверждение вроде "обеспечение бесконечной точности воспроизведения сигнала требует бесконечной частоты дискретизации". Ну, как бы да, ичо? Во-первых, это очевидно, во-вторых, это бесполезно.


Не согласен. Енто уже некий словарь ключевых теримнов и понятий, от которых можно оттолкнуться и вокруг которых можно строить разговор, архитектуру. Аналогом К-Ш было введение понятия частоты, дискретизации,
желание воспроизвести сигнал и т.д. Базовые вещи и понятия. Далее идет сама т. К-Ш, количественная. И тут в мире распр. систем наступает затык. Вот допустим я хочу построить систему, где у меня будет
< 100 req/sec. я должен ..., а если >100000 req/sec. я должен... Т.е. количества у нас нет, нету математики формул и т.д. Но хотя бы есть ключевые понятия (CAP).


S>>Имеем распределенные системы, дано -- ограниченный по своим ресурсам

S>>компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP.
S>Ну это, конечно же, неправда.

Кроме Лэмпорта что-то еще было?

S>Это как раз очень плохо, т.к. в данном контексте термин "искусство" — ругательный. И я вижу, как систематизированная теория распределённых систем всё же строится. И для её построения нужно избегать мусора типа CAP, а заниматься нормальными инженерными расчётами и математическими обоснованиями.


Полностью согласен, но CAP выбрасыать не стоит.
Кодом людям нужно помогать!
Re[12]: CAP
От: Sharov Россия  
Дата: 15.08.19 10:02
Оценка:
Здравствуйте, Sinclair, Вы писали:


S>>В DDIA вообще ничего не вводится. Болтовня, немного обо всем. Если бы DDIA ввела бы понятия CAP в 2000 году, тогда да, согласен. Для 2019 это набор ссылок в конце глав, неплохой.

S>>CAP -- это набор ключевых понятий, которых не было и оне вдруг сформулировались. Стало понятно куда копать и над чем думать\работать. Енто уже большое дело!
S>А можно уточнить — какие именно "ключевые понятия" введены в CAP?

Был явно обозначен компромисс между C,A и P.

S>>Просто никто следущий шаг, количественный, не сделал или его просто невозможно сделать? Или он у каждой системы свой... Может мы не знаем, а оне есть?...

S>Почему не сделал? Сделал. Липтон и Сандберг, к примеру, доказали, что any algorithm implementing a sequentially consistent read-write registermust have|r|+|w| ≥d, where |r| is the latency of a read operation, |w| is the latency of a write operation,and d is the network delay. Это как бы 1988. Аттия и Уэлч в 1995 доказывают, что any algorithm implementing a linearizable read-write register must have an operation latency of at least u/2, where u is the uncertainty of delay in the network between replicas.

S>Это к вопросу о том, что до CAP "никто не занимался распределёнными системами", ага.


Я, возможно, был не совсем точен. Безусловно занимались, но вот обощить все енто дело и свести к простым понятием до CAP не смогли.

S>>Это, вероятно, работа Лэмпорта и есть, еще годов 70-х.

S>Нет, Лэмпорт в нашем ВЦ совершенно точно не работал.

Что не мешает цитировать его работы:"Time, Clocks, and the Ordering of Events in a Distributed System".

S>>Благодаря CAP состоялась не одна система, которой, вероятно, мы пользуемся каждый день. Огромному число архитекторов сэкномили время на изобретения велосипедов и решения несущственных проблем,

S>>четко указав чем мы жертвуем в том или ином случае. Польза есть и немалая.
S>Чего? Какие системы "состоялись благодаря CAP"? Вы, коллега, что-то путаете.

Не состоялсь, а началось активное развитие. Что-то типа NoSql.
Кодом людям нужно помогать!
Re[13]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.08.19 13:48
Оценка:
Здравствуйте, Sharov, Вы писали:
S>Был явно обозначен компромисс между C,A и P.
Конкретнее можно? Чтобы говорить о каких-то компромиссах нужно внятно определить C, A, и P.
И вот Брюер начинает за здравие, говоря что A, вообще-то, измеряется в процентах. Но затем, ближе к формулировке теоремы, внезапно уходит к понятию "highly available", которое требует, чтобы произвольный запрос достигал конкретно заданной ноды. Вы для сравнения вернитесь к началу DDIA, повнимательнее прочитайте определения. Они важны.

S>Я, возможно, был не совсем точен. Безусловно занимались, но вот обощить все енто дело и свести к простым понятием до CAP не смогли.

CAP — плохое "сведение к простым понятиям".

S>Не состоялсь, а началось активное развитие. Что-то типа NoSql.

Конкретнее? Мне кажется, у вас какое-то искажённое представление о роли CAP в NoSQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: CAP
От: Sharov Россия  
Дата: 15.08.19 14:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Был явно обозначен компромисс между C,A и P.

S>Конкретнее можно? Чтобы говорить о каких-то компромиссах нужно внятно определить C, A, и P.

В вики.

S>>Не состоялсь, а началось активное развитие. Что-то типа NoSql.

S>Конкретнее? Мне кажется, у вас какое-то искажённое представление о роли CAP в NoSQL.

Возможно, ибо с NoSql я не работал. Но насколько я понимаю, благодаря CAP, явно поняв компромиссы, люди начали их(NoSql) активнее использовать. CAP понятнее чем
"linearizable read-write register" и т.п. Вы же не будете спорить, что для людей, которые хотят построить какое-нибудь расп. приложение, типа соц. сети или блогов,
от CAP больше толку чем от процитированных выше работ 70\80-х годов. Для людей, которые пилят движки распр. бд, типа NoSql,riak и т.п. CAP уже будет не столь полезен, кмк.
Кодом людям нужно помогать!
Re[15]: CAP
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.08.19 22:26
Оценка:
Здравствуйте, Sharov, Вы писали:

S>В вики.

Я-то думал вы реально Брюера читали

S>Возможно, ибо с NoSql я не работал. Но насколько я понимаю, благодаря CAP, явно поняв компромиссы, люди начали их(NoSql) активнее использовать. CAP понятнее чем

S>"linearizable read-write register" и т.п. Вы же не будете спорить, что для людей, которые хотят построить какое-нибудь расп. приложение, типа соц. сети или блогов,
S>от CAP больше толку чем от процитированных выше работ 70\80-х годов. Для людей, которые пилят движки распр. бд, типа NoSql,riak и т.п. CAP уже будет не столь полезен, кмк.
А, ну в таком смысле, наверное, да. Популяризация — штука важная.
Но мы-то, коллега, не журналистами работаем. С точки зрения технаря, а не гуманитария, CAP — это булшит.
Важно понимать, почему — чтобы красивые аббревиатуры не заслоняли смысл важных величин.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: DB internals, книги/блоги и т.п.
От: _ABC_  
Дата: 04.09.19 05:07
Оценка:
Здравствуйте, Stalker., Вы писали:

S>странно что Кalen Delaney никто не упомянул, ее набор книг по внутреннястям сервера абсолютная классика

Согласен. Мне посчастливилось в своё время попасть на её семинар. Могу точно сказать, что она реально весьма глубоко разбирается в том, о чем пишет и чему учит. Да и книги хорошие.
Re: DB internals, книги/блоги и т.п.
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 04.09.19 06:04
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>так как ссылки на исходники бесценны.


Может тогда и почитать исходники, ведь как бы ни была хороша документация или книга, код она не заменит.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.