Мне понравился опыт прошлого расследования по фейсбуку, и я решил организовать очередную серию, теперь про Amazon. Для нетерпеливых — в самом конце статьи описан итоговый вариант архитектуры Amazon S3 и проанализированы его свойства.

Не так давно Амазон объявил о переходе S3 с модели eventual consistency на strong consistency, то есть, предоставления гарантии read-after-write, чтения того, что было только что записано. Сообщество отреагировало, но как-то очень вяло: Amazon S3 Now Delivers Strong Read-After-Write Consistency

Первое, что лично мне подумалось в ответ на эти новости: а как же теорема CAP?

Автор выражает благодарность людям, которые помогли в написании статьи:

И в особенности Махешу Балакришнану, к числу почитателей которого я присоединился:

Ничто как фундаментальный архитектурный подход

Когда я предложил перевести на русский мою последнюю статью Easy Concurrency with Python Shared Objects на английском, поступило предложение "написать в несколько раз короче и понятнее". Просьба более чем обоснована. Поскольку я уже порядка десяти лет пишу многопоточку и БД, то описываемые мной логические связи выглядели самоочевидно, и я ошибочно расчитывал на аудиторию из трех с половиной человек, которые сидят сейчас где-то в яндексе или гугле. Судя по всему, они там и сидят, но тема им не интересна, поскольку в питоне нет настоящих потоков, а значит для этих людей такого языка программирования не существует. Потому я немножко снижаю планку и делаю общий обзор проблематики параллельных вычислений для людей, которые в них разбираются, но не являются экспертами в области.

Из-за чего весь сыр-бор?

Project repository.
Year old article about general concepts of the project.

So you want to build a multitasking system using python? But you actually hesitate because you know you'll have to either use multitasking module, which is slow and/or somewhat inconvenient, or a more powerfull external tool like Redis or RabbitMQ or even large DBMS like MongoDB or PostgreSQL, which require some glue (i.e. very far from native python code) and apply their own restrictions on what you can do with your data. If you think «why do I need so much hassle if I just want to run few worker threads in python using the data structures I already have in my python program and using functions I've already written? I just want to run this code in threads! Oh, I wish there was no GIL in Python» — then welcome to the club.

Of course many of us can build from scratch a decent tool that would make use of multiple cores. However, having already existing working software (Pandas, Tensorflow, SciPy, etc) is always cheaper than any development of new software. But the status quo in CPython tells us one thing: you cannot remove GIL because everything is based on GIL. Although making shit into gold could require much work, the ability to alleviate the transition from slow single-threaded shit to a slow not-so-single-threaded gold-looking shit might be worth it, so you won't have to rewrite your whole system from scratch.

Intro

So you are writing some CPU-intensive code in Python and really trying to find ways out of its single-threaded prison. You might be looking towards Numba's "nopython parallel" mode, you might be using forked processes with multiprocessing, you might be writing microservices with database-like coordinators, or even writing your own multithreaded programs in C/C++ just like creators of TensorFlow did.

In this article I'm describing a rationale for my pet project where I try to implement facilities for general purpose multitasking to be used in a form of simple python code, employing a database-like approach for interpreters communication, while keeping the GIL (Global Interpreter Lock) and trying to be as pythonic as possible.

It could also become handy in the light of upcoming multiple interpreters support in CPython.

As far as I know, nobody came that far in trying to provide Python program with native shareable storage. The last closest attempt was Python Object Sharing which is pretty much dead by now. I hope my project won't meet the same fate.

— Сколько нужно архитекторов, чтобы реализовать язык программирования?
— Сто. Один будет писать реализацию, а 99 — говорить, что могут сделать лучше.

В этой статье я хочу затронуть не столько сам язык, сколько детали реализации CPython и его стандартной библиотеки, которые гарантируют, что у вас не будет никаких простых способов сделать приложение на питоне ни многопоточным, ни быстрым, ни легко поддерживаемым, и почему было создано столько альтернативных реализаций (PyPy, Cython, Jython, IronPython, Python for .NET, Parakeet, Nuitka, Stackless, Unladen Swallow), половина из которых уже умерла; и мало кто понял, почему у альтернатив не было шансов победить в борьбе за выживание против других языков. Да, есть GDScript, который призван решить проблемы с производительностью, есть Nim, который призван решить вообще все проблемы, не обязывая при этом пользователя чрезмерно явно объявлять типы. Однако, учитывая огромную инертность индустрии, я осознаю, что в ближайшие 10 лет новые языки точно не займут значимой ниши. Однако, я верю в то, что питон возможно сделать эффективным, изменив стиль написания кода, по большей части сохранив оригинальный синтаксис, и полностью сохраняя возможность взаимодействия кода нового и старого стиля. Я буду концентрироваться на проблемах CPython, а не ближайшего его конкурента, PyPy, поскольку PyPy на самом деле прыгает вокруг всё тех же проблем CPython.