Почему люди предпочитают панды SQL?


69

Я использую SQL с 1996 года, поэтому я могу быть предвзятым. Я широко использовал MySQL и SQLite 3, но также использовал Microsoft SQL Server и Oracle.

Подавляющее большинство операций, которые я видел в Pandas, можно сделать проще с помощью SQL. Это включает в себя фильтрацию набора данных, выбор определенных столбцов для отображения, применение функции к значениям и т. Д.

Преимущество SQL заключается в наличии оптимизатора и сохранности данных. SQL также имеет сообщения об ошибках, которые являются ясными и понятными. У Pandas есть несколько загадочный API, в котором иногда уместно использовать один [ stuff ], в других случаях, когда вам нужно [[ stuff ]], а иногда вам нужно .loc. Часть сложности панд возникает из-за того, что происходит так много перегрузок.

Поэтому я пытаюсь понять, почему Панды так популярны.


Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Шон Оуэн

Ответы:


51

Реальный первый вопрос - почему люди более продуктивны с абстракциями DataFrame, чем с чистыми абстракциями SQL.

TLDR; DataFrames не ориентированы на (человеческий) процесс разработки и отладки SQL.

Основная причина в том, что абстракции DataFrame позволяют создавать операторы SQL, избегая при этом многословного и неразборчивого вложения. Шаблон написания вложенных подпрограмм, комментирования их для проверки и последующего раскомментирования заменяется отдельными строками преобразования. Вы можете, естественно, построчно запускать вещи в репле (даже в Spark) и просматривать результаты.

Рассмотрим пример добавления нового преобразованного (столбца с искаженной строкой) таблицы, затем группировки по ней и выполнения некоторых агрегаций. SQL становится довольно уродливым. Pandas может решить эту проблему, но упускает некоторые вещи, когда дело касается действительно больших данных или определенных разделов (возможно, улучшенных в последнее время).

Кадры данных следует рассматривать как высокоуровневый API для подпрограмм SQL, даже если с пандами они вообще не отображаются в каком-либо планировщике SQL.

-

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

Одна простая причина, по которой вы можете увидеть гораздо больше вопросов относительно манипулирования данными Pandas, нежели SQL, состоит в том, что использование SQL по определению означает использование базы данных, а во многих случаях использования в наши дни просто требуется бит данных для ' готовые задачи (из .csv, web api и т. д.). В этих случаях загрузка, хранение, манипулирование и извлечение из базы данных нежизнеспособны.

Однако, учитывая случаи, когда сценарий использования может оправдывать использование Pandas или SQL, вы, конечно, не ошибаетесь. Если вы хотите выполнить много повторяющихся задач по обработке данных и сохранить результаты, я всегда рекомендовал бы сначала попробовать пройти через SQL. Из того, что я видел, причина, по которой многие пользователи, даже в этих случаях, не используют SQL, заключается в двух аспектах.

Во-первых, главное преимущество панд перед SQL заключается в том, что он является частью более широкой вселенной Python, что означает, что одним махом я могу загружать, очищать, манипулировать и визуализировать свои данные (я даже могу выполнять SQL через Pandas ...). Другое дело, что слишком многие пользователи не знают степени возможностей SQL. Каждый новичок изучает «синтаксис извлечения» SQL (SELECT, FROM, WHERE и т. Д.) Как средство для передачи ваших данных из БД в другое место. Некоторые могут использовать более продвинутый синтаксис группировки и итерации. Но после этого, как правило, появляется значительный разрыв в знаниях, пока вы не обратитесь к экспертам (администраторы баз данных, инженеры данных и т. Д.).

tl; dr: это часто зависит от варианта использования, удобства или пробела в знаниях о возможностях SQL.


2
Я думаю, что SQL в значительной степени основан на множестве, и это играет большую роль, когда множество людей из других технических областей привыкли обрабатывать данные построчно. Также учтите, что данные - это в основном просто данные для панд, но разные движки SQL поддерживают разные встроенные функции, которые могут очень быстро раздражать, если вам придется рубить и менять в течение рабочего дня
Дейв

3
Я бы не сказал, что это нежизнеспособно. Если вы можете поместить данные в фрейм данных Pandas, вы, вероятно, можете поместить их в базу данных PostgreSQL. Но с одной стороны и готово, это, вероятно, больше усилий и времени, чем вы могли бы сэкономить.
jpmc26

2
Я согласен с тем, что некоторые подходы к ETL являются решениями, ориентированными на программиста. То есть они предпочитают манипулировать данными, а затем представлять эту «идеальную» полезную нагрузку в базу данных. Однако, как вы указали, если это можно сделать с помощью нескольких SQL-запросов, то дополнительный программный уровень не нужен. Именно с чем я столкнулся недавно. Как указывает ОП и ваш ответ, это могут быть люди старой школы или администраторы баз данных, которые смотрят на это и говорят, почему бы не сделать это в SQL (даже просто несколькими простыми запросами!). Тем не менее, я обнаружил, что панды очень мощные для чрезвычайно разнообразных наборов данных.
SaltySub2

1
@SaltySub Просто пункт о том, как перенести вещи из программного уровня в SQL: это справедливо и может быть совершенно приемлемым, но даже если зайти в логику приложения в процедурах SQL, это может привести к особой головной боли.
Электрическая головка

1
@ElectricHead Я согласен, что должен быть правильный баланс. Если ряд запросов SQL может выполнить задачи адекватно, это, безусловно, может быть проще и эффективнее. И наоборот, как вы указываете, если нужно разместить огромное количество логики в процедурах SQL и т. Д., Тогда панды должны быть строго рассмотрены. В частности, как указано выше, если вы используете разные варианты баз данных - различия в синтаксисе SQL могут быть очень сложными.
SaltySub2

29

Хотя применение этих двух вещей частично совпадает, это сравнивает яблоки с апельсинами.

Pandas - это инструмент для анализа данных, реализованный на Python, языке программирования общего назначения. SQL является предметно-ориентированным языком для запроса реляционных данных (обычно в системе управления реляционными базами данных, примерами которой являются SQLite, MySQL, Oracle, SQL Server, PostgreSQL и т. Д.).

SQL подразумевает

  • работа с данными в СУБД *, которая может подходить или не соответствовать рабочей нагрузке, даже если это небольшая база данных SQLite,
  • знание области базы данных (как конечный пользователь, разработчик и / или администратор; предположение, что «SQL быстрее», которое я часто вижу, является чрезмерным упрощением), и
  • преодоление немаловажной кривой обучения эффективному использованию SQL, особенно в специализированных приложениях, таких как анализ данных (в отличие от создания простых отчетов с простыми данными).

* Стоит подчеркнуть тот факт, что SQL настолько специфичен для домена, что становится все менее актуальным для работы со все более распространенными альтернативами реляционным базам данных, такими как базы данных NoSQL . Это представляет фундаментальный сдвиг в том, как данные хранятся и структурируются, и на самом деле не существует универсально распространенного способа доступа к ним, как развитие стандартизации SQL, нацеленное на достижение.

С другой стороны, Python (pandas довольно «питонический», так что здесь это справедливо) является гибким и доступным для людей из разных слоев общества. Его можно использовать как «язык сценариев», как функциональный язык и полнофункциональный язык ООП. Возможности визуализации и совместимость с источниками данных встроены в панды, но вы можете свободно включать все, что Python может делать, в ваш рабочий процесс (а это большинство вещей); научная экосистема Python раздулась и включает в себя отличные инструменты, такие как Jupyter Notebook, и необходимые библиотеки scipy, такие как matplotlib и numpy (на которых строится pandas). Важными элементами анализа данных панд является RВдохновленный, и вы, как правило, не найдете статистиков, которые умничают и ахают о том, используют ли они R (или, возможно, все чаще панд!) вместо того, чтобы помещать все в базу данных и писать свои анализы в SQL.

Я не говорю, что pandas лучше, чем SQL или наоборот, но SQL - это очень специфичный для домена инструмент, тогда как pandas является частью гигантской, гибкой и доступной экосистемы. Я работаю с системами геопространственных данных, огромную роль в которых играют реляционные базы данных, а SQL является мощным и важным инструментом. Тем не менее, панды - в равной степени, если не более важная часть моего повседневного инструментария, и SQL часто отводится для извлечения данных - возможно, с некоторой предварительной обработкой - так что я могу что-то делать с ними в пандах.


1
Это единственный верный ответ, он должен быть выбранным. SQL и Pandas - это две разные вещи, я не понимаю, что люди пытаются сравнить.
Генет

Я подозреваю, что это конечный пользователь, пишущий что-то наподобие кода, чтобы извлекать и массировать некоторые данные откуда-то и выплевывать некоторые числа. Я не совсем удивлен; У меня был непосредственный опыт того, как аналитики данных, представленные со старой, но в остальном ничем не примечательной, базой данных Oracle, даже не представляли себе, что это такое и как к нему подключиться, не говоря уже о выводе данных. Я полагаю, что это указывает на фундаментальное отсутствие понимания технологии - я фактически добавил немного, чтобы, надеюсь, подчеркнуть, как быстро исчезает непонимание объема SQL.
Электрическая головка

Я бы поспорил с вами о том, что вы не относитесь к ситуациям с NoSQL. Рассмотрим, например, успехи, достигнутые PostgreSQL с его хранилищем JSON.
jpmc26

Я старался тщательно подбирать слова; PostgreSQL по-прежнему является СУБД, несмотря на то, что делает много вещей хорошо (как SQL Server, несмотря на поддержку графиков). Но я немного смягчил формулировку, потому что это все еще хороший момент: есть некоторое пересечение и, что важно, API-интерфейсы SQL существуют для некоторых систем NoSQL. Это является кроссовер , хотя, SQL не является универсальным языком , а не все данные структурированы реляционными.
Электрическая голова

Я думаю, что вы можете делать все в SQL, что возможно в пандах. SQL не гибок, но так сильно оптимизирован.
Медиа

22

Во-первых, панды не так уж популярны. Я использую как панд, так и SQL. Сначала я пытаюсь понять задачу - если это можно сделать на SQL, я предпочитаю SQL, потому что он более эффективен, чем pandas. Попробуйте работать с большими данными (10 000 000 x 50). Попробуйте выполнить некоторые групповые операции как в SQL, так и в пандах. Ты поймешь.

Я использую панд там, где это удобно, например, разбивая значения столбца на массив и выполняя некоторые операции с ним (например, выбирая только некоторые значения из этого массива). Теперь этот вид задачи довольно сложно кодировать на SQL, но pandas облегчит вашу задачу.


Эта неэффективность специфична для панд? Я провел довольно много манипуляций с данными в памяти в C # и нашел его довольно простым и эффективным, если он уместился в памяти и был однократным (т.е. не нужно постепенно обновлять индексы при изменении данных).
CodesInChaos

Предполагается, что панды удобнее, чем быстрые, но это не значит, что они не могут быть быстрыми, если вы правильно их используете. В конце концов, выполнение SQL-запроса данных в базе данных не волшебство - для этого требуются ресурсы, как угодно, просто (если вы все сделаете правильно!) Вы надеетесь использовать ресурсы на тщательно настроенных, мощных серверах баз данных. , Получение вашего конвейера прямо в pandas или подобном (например, потоковая передача данных, а не загрузка их в память) определит, насколько успешными будут некоторые усилия.
Электрическая головка

@CodesInChaos Есть этот ответ панд против SQl - qr.ae/TUIpzE . Там описаны преимущества и недостатки использования панд.
Анкит Сет

12

Я один из тех людей, которые будут использовать (в моем случае) dplyr R (язык, не обязательно инструмент) в любом случае, если бы я мог, даже если я знаю свой SQL.

Основное преимущество, которое я вижу в конвейерах Pandas / dplyr / data.table, заключается в том, что операции являются атомарными и могут быть прочитаны сверху вниз.

В SQL вам нужно проанализировать весь сценарий, прыгая (что суммируется, что объединяется и как - слева? Внутреннее? Право ?, применяются ли какие-либо фильтры?), Чтобы полностью понять, что происходит.

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

И да, вы можете делать WITHоператоры и тому подобное, но это требует гораздо больше кода и не так ясно, какой объект используется по сравнению с конвейером.


6

Я довольно новичок в Pandas / Python, но уже более 20 лет являюсь администратором баз данных SQLServer, архитектором, администратором и т. Д. Я люблю Pandas, и я стараюсь всегда стараться заставить вещи работать в Pandas, прежде чем вернуться к себе, уютный мир SQL.

Почему РСУБД лучше Преимущество СУБД заключается в их многолетнем опыте оптимизации скорости запросов и операций чтения данных. Что впечатляет, так это то, что они могут сделать это, одновременно уравновешивая необходимость оптимизировать скорость записи и управлять высококонкурентным доступом. Иногда эти дополнительные накладные расходы отклоняют преимущество для Pandas, когда речь идет о простых, однопользовательских сценариях использования. Но даже в этом случае опытный администратор баз данных может настроить базу данных так, чтобы она была оптимизирована для скорости чтения и скорости записи. Администраторы баз данных могут использовать преимущества таких вещей, как оптимизация хранения данных, стратегический размер страниц на диске, заполнение / заполнение страниц, стратегии контроллера данных и разбиения диска, оптимизированные планы ввода-вывода, закрепление данных в памяти, предварительно определенные планы выполнения, индексирование, сжатие данных и многое другое. У многих разработчиков Pandas складывается впечатление, что они не не понимаю глубину, которая доступна там. Обычно я думаю, что если разработчик Pandas никогда не имеет данных, достаточно больших для такой оптимизации, они не понимают, сколько времени они могут спасти вас из коробки. Мир RDBMS обладает 30-летним опытом оптимизации этого, поэтому, если необходима необработанная скорость для больших наборов данных, RDBMS можно превзойти.

Почему Python / Pandas лучше: Тем не менее, скорость это не все, и во многих случаях не является движущим фактором. Это зависит от того, как вы используете данные, разделяют ли они, и заботитесь ли вы о скорости обработки. СУБД, как правило, более жесткие в своих структурах данных и возлагают на разработчика бремя быть более детерминированным с формами данных. Панды позволяют вам быть более свободным здесь. Кроме того, и это моя любимая причина, вы на настоящем языке программирования. Языки программирования дают вам бесконечно большую гибкость в применении передовой логики к данным. Конечно, существует также богатая экосистема модулей и сторонних сред, к которым SQL не может приблизиться. Возможность перехода от необработанных данных к веб-презентации или визуализации данных в одной кодовой базе ОЧЕНЬ удобна. Это также намного более портативно. Вы можете запускать Python практически где угодно, включая общедоступные записные книжки, которые могут расширить область ваших результатов, чтобы быстрее добраться до людей. Базы данных не преуспевают в этом.

Мой совет? Если вы обнаруживаете, что переходите на все большие и большие наборы данных, вы обязаны сделать решающий шаг и узнать, как СУРБД могут помочь. Я видел миллион строк, объединение в несколько таблиц, суммарные запросы, настроенные с 5 минут до 2 секунд. Имея это понимание в своем поясе инструментов, вы становитесь специалистом по обработке данных. Вы можете быть в состоянии сделать все в Pandas сегодня, но однажды у вас может быть задание, где RDBMS является лучшим выбором.


5

Что может сделать Pandas, чего не может сделать SQL

  1. df.describe()
  2. Черчение, например df['population'].plot(kind='hist')
  3. Используйте фрейм данных непосредственно для обучения алгоритмам машинного обучения

Вещи, которые может сделать Панда, я не знал, что SQL может сделать также

  1. Экспорт в CSV: df.to_csv('foobar.sv'). Это важно, когда вы хотите показать что-то владельцу бизнеса, который хочет работать с Excel. И там df.to_excelтоже. Но в SQL это можно сделать SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(спасибо, vy32!)

1
Приятно. Хотя большинство из них выглядят как функции, которые могут быть реализованы в SQL. (SQL имеет прямой экспорт CSV.)
vy32

Не могли бы вы отправить мне запрос, который экспортирует в CSV? (Я знаю только инструменты, которые делают это для некоторых баз данных на основе SQL, но я никогда не видел запрос ... поэтому я сомневаюсь, что это является частью спецификации SQL)
Martin Thoma

1
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table; См dev.mysql.com/doc/refman/8.0/en/select-into.html
vy32

Большое вам спасибо, vy! Я думаю, что я скорректирую свой ответ, когда я дома :-)
Мартин Тома

Конечно вещь. Помните, что файл попадает на сервер SQL, а не на клиент.
vy32

3

Единственное, что не отражено в этих ответах, о которых я хотел бы упомянуть, это то, что это также зависит от того, как вы используете SQL. Возьмите arcpy, например. По какой-то причине ни одна из функций arcpy.da не имеет функции execute много. Это действительно странно, потому что почти все остальные библиотеки Python sql делают. Оператор Where в функциях arcpy.da также ограничен примерно 120 символами. По сути, это означает, что, если у вас есть относительно большое количество вещей, которые вы пытаетесь сделать с вашей базой данных, ваш единственный реальный выбор - вызывать выбранную вами функцию arcpy.da несколько раз, меняя оператор where каждый раз, когда вы делаете это. Есть несколько приемов, которые вы можете использовать, чтобы ускорить этот процесс - например, вы можете перебирать фрагменты вашего набора данных - но буквально каждый из этих приемов намного медленнее, чем просто использование одного arcpy.da. searchcursor для загрузки всей вашей таблицы во фрейм данных pandas, а затем манипулирования ею с использованием pandas, numpy, и, если ваши данные действительно такие большие, dask. Здесь я должен подчеркнуть, что в этом случае панды не просто немного быстрее. Это отвратительно быстрее. Это так быстро, что я буквально смеялся над собой за то, что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут. Это было так быстро, что я буквально смеялся над собой, потому что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут. Это было так быстро, что я буквально смеялся над собой, потому что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут.

Стоит отметить, что хотя я мог бы сделать это с помощью sql, мне потребовалось бы гораздо больше времени на изучение. Мне бы пришлось либо изучать операции специально для SQL в Access - вот где заканчивались данные для этого скрипта - SQL в Access был не так надежен, как мне было нужно, когда я действительно собирался это делать, или Мне пришлось бы записать все свои данные в базу данных sqlite3, манипулировать ими там, а затем поместить в Access. Хотя это могло дать мне аналогичные результаты производительности, в будущем мой сценарий было бы сложнее модифицировать.

Так что да, иногда Pandas и просто строго лучше, чем использовать опции sql, которые есть в вашем распоряжении . Все, что мне нужно было сделать в sql, было сделано с помощью функции в pandas. Вы также можете использовать синтаксис sql с пандами, если хотите. Есть небольшая причина не использовать панд и sql в тандеме.

Еще одна вещь, которую я хочу упомянуть о Pandas и numpy, заключается в том, что обе эти библиотеки по своей природе основаны на множестве подходов. Вы можете циклически проходить по фреймам данных и строить серии с помощью этих библиотек, но действительно трудно изменить данные в этих структурах таким образом, чтобы в итоге вы написали более эффективный код - на основе набора - с обеими этими библиотеками просто потому, что намного проще делать. «Руководствуясь», если не использовать методику, основанную на множестве, я не сталкивался с SQL.

Еще одна важная вещь, которую я забыл упомянуть с Пандами. Деньги . Pandas - это инструмент, который многие специалисты по науке о данных хотят, чтобы вы знали, как им пользоваться. Почти каждая работа по науке о данных, на которую я смотрел, платила больше, чем работа по управлению базами данных. Единственное исключение из этого, которое я заметил, - это Data Engineering, но я видел гораздо меньше таких вакансий. Панды, похоже, с первого взгляда приносят вам больше денег.


5
Возможно, грустно, что когда речь идет о современных рабочих местах, речь идет о правильных модных словах в вашем резюме, а не о подходах, которые вы используете для решения проблемы (при условии, что вы можете выучить упомянутое модное слово относительно быстро). Словно модное слово важнее решения проблем. Когда решение проблемы для X должно включать изучение и использование технологий A, B, C, а не наоборот. Интересно, если большинство команд разработчиков сейчас разбираются с вещами из-за модности и модности, то думают о решении проблем как о вторичной или «старой школе», потому что вы не знали / не использовали упомянутое модное слово.
SaltySub2

1
@ElectricHead По моему опыту, если вы пишете свою собственную функцию с использованием sql в python, проще просто неправильно использовать курсор и писать неверные запросы, чем при использовании pandas / numpy. Следует помнить, что не все модули / библиотеки sql сделаны одинаково. В моем случае, с arcpy.da.SearchCursors и т. П., Действительно нет хорошего способа сделать что-то с кучей записей эффективно из-за странных ограничений. Если я использую pandas / numpy, то становится одним хорошим способом сделать что-то, и это то, чего я хочу при использовании python.

1
ААА понятно. Вы имеете в виду homespun SQL конвейер через реализацию Python dbapi против использования numpy / pandas? В таком случае, да, нет, у меня нет никаких аргументов; требуется забота! Он читается как простой SQL, с которым вам, очевидно, нужно разбираться в операциях над множествами, но он довольно быстро это выяснит при выполнении глупых запросов от клиента базы данных.
Электрическая головка

1
@Steve Да, не остановит людей, пытающихся динамически изменять вещи в циклах в пандах или аналогичных программах :) Я думаю, что понимание SQL помогает эффективно работать в пандах (хотя они не скрывают сходства в некоторых концепциях).
Электрическая головка

1
@Steve Действительно, панды тоже сильны ... Я думаю, одно из моих разочарований - это то, что разработчики и менеджмент, включая меня, не тратят достаточное время на оценку решений и погоню за тенденциями (когда деньги продвигают себя / компанию). Но даже в бедном прототипировании / mvp нужно было бы заложить соответствующую основу для масштабирования. SQL, noSQL и Pandas ... все имеют свои цели для соответствующих задач и проектов на разных этапах. За прошедший год плюс, noSQL для экономного прототипа / mvp определенно помог мне больше, чем один. SQL был бы излишним для этого.
SaltySub2

3

Я думал, что добавлю, что я делаю много анализа данных на основе временных рядов, и панды resampleи reindexметоды неоценимы для этого. Да, вы можете делать подобные вещи в SQL (я склонен создавать DateDimensionтаблицу для помощи с запросами, связанными с датами), но я просто считаю, что методы pandas намного проще в использовании.

Кроме того, как говорили другие, остальная часть моего моделирования находится на Python, и у меня часто бывают веб-звонки или файлы CSV.


2

Я попытаюсь ответить на этот вопрос, основываясь на собственном опыте. В отличие от других ответов, я предпочитаю Sqlглубокое обучение и связанные с большими данными вещи. Для этого есть множество причин. Как это видно здесь ,

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

B+

Другое отличие состоит в том, что операции CRUD в Sql могут применяться с распределенными политиками авторизации, которые в пандах невозможны.

Это не значит, что лучше, все зависит от вашей задачи. Для крупномасштабных вычислений я предпочитаю Sql, а для маленьких я предпочитаю панд.

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


1

Panda более популярен, так как python в виде ноутбуков jupyter является наиболее популярным набором инструментов, который используется исследователем в области нейронных сетей. Python становится "языком". Можно даже использовать бэкэнд SQL, но вы не привязаны к SQL только с помощью panda.


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.