Post #1875
1.69K
Вертикальное и горизонтальное масштабирование базы данных (к предыдущему посту)
Channel Public Channel
ME - Subscribers
- 5.81K
- Photos
- 1.8K
- Videos
- 86
- Links
- 1.3K
Showing posts older than #1877 · Back to latest
Older Posts 18 shown
Post #1874
1.74K
Как масштабировать базы данных?
Партиционирование (разделение) базы данных — это процесс разделения большой таблицы или базы данных на более мелкие, удобные для управления части, известные как партиции. Это позволяет нам запрашивать только части данных, что ускоряет их загрузку.
В целом существует два типа партиционирования:
1. Горизонтальное партиционирование (шардинг). Разделяет таблицы по строкам, при этом каждая партиция содержит одинаковую схему, но разные строки. Идеально подходит для многопользовательских приложений, где данные можно разделить по клиентам или пользователям для распределённых вычислений, или когда данные слишком велики для хранения в одной базе данных.
Существуют различные виды шардинга:
* Хеш-шардинг (Hash-based sharding). Шард определяется с помощью хеш-функции на определённом ключевом столбце в каждой записи. Эта хеш-функция равномерно распределяет записи по доступным шардам. Основное преимущество — равномерное распределение данных и нагрузки, но это может усложнить запросы, охватывающие несколько шардов, и затруднить повторную шардизацию.
* Ранг-шардинг (Range-based sharding). Разделение данных на шарды на основе диапазонов определённого ключа. Например, идентификаторы клиентов от 1 до 1000 могут храниться в одном шарде, а идентификаторы 1001–2000 — в другом. Этот подход упрощает запросы, включающие операции с диапазонами, но может привести к неравномерному распределению данных и горячим точкам, если данные распределены неравномерно.
* Директивный шардинг (Directory-based sharding). Этот метод использует справочную таблицу для сопоставления ключей с соответствующими шардами. Он обеспечивает отличную гибкость, позволяя легко добавлять или удалять шарды и выполнять простую повторную шардизацию.
При шардинге каждый сервер базы данных должен быть структурно идентичен, а записи данных должны быть разделены по шардированной базе данных.
2. Вертикальное партиционирование. Разделяет таблицы по столбцам или таблицам, отделяя часто используемые столбцы от менее используемых, оптимизируя время доступа и эффективность кэширования. Таким образом, каждая таблица может быть размещена в отдельной базе данных.
Однако шардинг базы данных — сложная задача. Это отнимает много времени, поскольку необходимо настроить множество вещей, таких как перемещение данных и сопоставление запросов. Кроме того, это требует финансовых затрат.
Вот несколько эффективных практик при возникновении проблем с базой данных:
1. Вертикальное масштабирование — добавление дополнительных ресурсов на сервер БД (CPU, память и т. д.).
2. Репликация — создание реплики для чтения из вашей БД. Это помогает улучшить производительность чтения, но также необходимо включить кэширование.
Если всё вышеперечисленное не помогает, то можно прибегнуть к партиционированию:
* Используйте горизонтальное партиционирование для больших таблиц, где масштабируемость и производительность для определённых запросов имеют решающее значение.
* Используйте вертикальное партиционирование, когда у вас есть таблицы со множеством столбцов, но не все они часто используются вместе.
Партиционирование (разделение) базы данных — это процесс разделения большой таблицы или базы данных на более мелкие, удобные для управления части, известные как партиции. Это позволяет нам запрашивать только части данных, что ускоряет их загрузку.
В целом существует два типа партиционирования:
1. Горизонтальное партиционирование (шардинг). Разделяет таблицы по строкам, при этом каждая партиция содержит одинаковую схему, но разные строки. Идеально подходит для многопользовательских приложений, где данные можно разделить по клиентам или пользователям для распределённых вычислений, или когда данные слишком велики для хранения в одной базе данных.
Существуют различные виды шардинга:
* Хеш-шардинг (Hash-based sharding). Шард определяется с помощью хеш-функции на определённом ключевом столбце в каждой записи. Эта хеш-функция равномерно распределяет записи по доступным шардам. Основное преимущество — равномерное распределение данных и нагрузки, но это может усложнить запросы, охватывающие несколько шардов, и затруднить повторную шардизацию.
* Ранг-шардинг (Range-based sharding). Разделение данных на шарды на основе диапазонов определённого ключа. Например, идентификаторы клиентов от 1 до 1000 могут храниться в одном шарде, а идентификаторы 1001–2000 — в другом. Этот подход упрощает запросы, включающие операции с диапазонами, но может привести к неравномерному распределению данных и горячим точкам, если данные распределены неравномерно.
* Директивный шардинг (Directory-based sharding). Этот метод использует справочную таблицу для сопоставления ключей с соответствующими шардами. Он обеспечивает отличную гибкость, позволяя легко добавлять или удалять шарды и выполнять простую повторную шардизацию.
При шардинге каждый сервер базы данных должен быть структурно идентичен, а записи данных должны быть разделены по шардированной базе данных.
2. Вертикальное партиционирование. Разделяет таблицы по столбцам или таблицам, отделяя часто используемые столбцы от менее используемых, оптимизируя время доступа и эффективность кэширования. Таким образом, каждая таблица может быть размещена в отдельной базе данных.
Однако шардинг базы данных — сложная задача. Это отнимает много времени, поскольку необходимо настроить множество вещей, таких как перемещение данных и сопоставление запросов. Кроме того, это требует финансовых затрат.
Вот несколько эффективных практик при возникновении проблем с базой данных:
1. Вертикальное масштабирование — добавление дополнительных ресурсов на сервер БД (CPU, память и т. д.).
2. Репликация — создание реплики для чтения из вашей БД. Это помогает улучшить производительность чтения, но также необходимо включить кэширование.
Если всё вышеперечисленное не помогает, то можно прибегнуть к партиционированию:
* Используйте горизонтальное партиционирование для больших таблиц, где масштабируемость и производительность для определённых запросов имеют решающее значение.
* Используйте вертикальное партиционирование, когда у вас есть таблицы со множеством столбцов, но не все они часто используются вместе.
- ❤ 7
- 🔥 2
- 👏 2
Post #1873
2.06K
Несколько дней назад исследователи по безопасности также обратили внимание на 28 NPM-пакетов, авторами которых было включено изменение категории Protestware. Изменение приводило к воспроизведению украинского гимна и отключению обработки событий от мыши на сайтах в доменных зонах "ru", "su", "by" и "рф", если пользователь ранее уже открывал сайт более трёх дней назад и в его браузере была включена поддержка русского языка.
https://socket.dev/blog/protestware-update-28-npm-packages-affected-by-payload-targeting-russian-language-users
https://socket.dev/blog/protestware-update-28-npm-packages-affected-by-payload-targeting-russian-language-users
- 😁 24
- 🤡 17
- 👎 3
- 🤮 3
- 🔥 2
- 😱 2
- 👏 1
- 🤬 1
- 💊 1
Post #1872
2.36K
На сопровождающих JavaScript-библиотеки на сервисе NPM была совершена масштабная фишинг-атака, в ходе которой от имени сервиса NPM было разослано сообщение о необходимости подтвердить свой email. Проведённая атака позволила злоумышленникам получить NPM-токены сопровождающего одного из крупных JavaScript-проектов и выпустить обновления с вредоносным кодом для пяти NPM-пакетов, в сумме насчитывающих около 100 млн загрузок в неделю.
Отправленное сопровождающим сообщение было стилизовано под типовые уведомления NPM, отправляемые с адреса "support@npmjs.org", но в качестве ссылки для перехода был указан домен "npnjs.com" вместо "npmjs.com" (третья буква "n" вместо "m").
В ходе атаки были сгенерированы новые версии пакетов:
eslint-config-prettier: 8.10.1, 9.1.1, 10.1.6, 10.1.7.
eslint-plugin-prettier: 4.2.2, 4.2.3.
synckit: 0.11.9.
@pkgr/core: 0.2.8.
napi-postinstall: 0.3.1.
В пакеты был добавлен вредоносный код для атаки на пользователей Windows - они загружали библиотеку node-gyp.dll с функциональностью для удалённого выполнения команд.
Неизвестно, сколько пользователей успело загрузить вредоносные версии (например, вредоносная версия пакета eslint-plugin-prettier оставалась в репозитории около двух дней), но данные пакеты довольно широко используются. Так, за прошлую неделю пакет eslint-config-prettier насчитывал 30 млн загрузок и использовался в качестве зависимости у 11762 тысячи пакетов, пакет eslint-plugin-prettier - 21 млн загрузок (8468 зависимых пакетов), synckit - 18 млн, @pkgr/core - 16 млн и napi-postinstall - 10 млн.
https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise
Отправленное сопровождающим сообщение было стилизовано под типовые уведомления NPM, отправляемые с адреса "support@npmjs.org", но в качестве ссылки для перехода был указан домен "npnjs.com" вместо "npmjs.com" (третья буква "n" вместо "m").
В ходе атаки были сгенерированы новые версии пакетов:
eslint-config-prettier: 8.10.1, 9.1.1, 10.1.6, 10.1.7.
eslint-plugin-prettier: 4.2.2, 4.2.3.
synckit: 0.11.9.
@pkgr/core: 0.2.8.
napi-postinstall: 0.3.1.
В пакеты был добавлен вредоносный код для атаки на пользователей Windows - они загружали библиотеку node-gyp.dll с функциональностью для удалённого выполнения команд.
Неизвестно, сколько пользователей успело загрузить вредоносные версии (например, вредоносная версия пакета eslint-plugin-prettier оставалась в репозитории около двух дней), но данные пакеты довольно широко используются. Так, за прошлую неделю пакет eslint-config-prettier насчитывал 30 млн загрузок и использовался в качестве зависимости у 11762 тысячи пакетов, пакет eslint-plugin-prettier - 21 млн загрузок (8468 зависимых пакетов), synckit - 18 млн, @pkgr/core - 16 млн и napi-postinstall - 10 млн.
https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise
- 🕊 16
- 😱 9
- 💊 7
Post #1871
1.93K
5 распространенных типов индексов в базах данных #database
- 👍 11
- 🔥 1
- 👏 1
Post #1870
1.93K
Вкратце как работает сеть контейнеров
- 🤯 13
- 👍 5
- 👏 1
Post #1869
1.94K
4. Client Key Exchange: клиент создаёт случайную строку байтов, называемую «premaster secret». Он шифрует её с помощью открытого ключа сервера, полученного из SSL-сертификата, и отправляет. Поскольку для шифрования используется алгоритм асимметричного шифрования, клиент знает, что сервер может получить секрет только если расшифрует его с помощью закрытого ключа (что подтверждает владение сертификатом).
5. Session Key Generation: сервер расшифровывает premaster secret с помощью закрытого ключа SSL-сертификата. Клиент и сервер независимо генерируют ключи сеанса локально, используя комбинацию client random, server random и premaster secret.
Поскольку они используют одни и те же данные и детерминированный алгоритм, они должны прийти к одинаковым результатам.
Если это не так, последующее шифрование/дешифрование данных при записи не будет соответствовать протоколу HTTP/HTTPS и завершится ошибкой.
💡 Шаг 5 косвенно подтверждает клиенту, что сервер владеет предоставленным им SSL-сертификатом (а не просто делает вид, что он у него есть).
После этого сеансовый ключ может использоваться для симметричного шифрования/дешифрования HTTP-данных.
5. Session Key Generation: сервер расшифровывает premaster secret с помощью закрытого ключа SSL-сертификата. Клиент и сервер независимо генерируют ключи сеанса локально, используя комбинацию client random, server random и premaster secret.
Поскольку они используют одни и те же данные и детерминированный алгоритм, они должны прийти к одинаковым результатам.
Если это не так, последующее шифрование/дешифрование данных при записи не будет соответствовать протоколу HTTP/HTTPS и завершится ошибкой.
💡 Шаг 5 косвенно подтверждает клиенту, что сервер владеет предоставленным им SSL-сертификатом (а не просто делает вид, что он у него есть).
После этого сеансовый ключ может использоваться для симметричного шифрования/дешифрования HTTP-данных.
- 👍 10
- 👏 3
- 🔥 2
Post #1868
1.8K
Как работает HTTPS. (описание к предыдущему посту)
Прежде всего есть два протокола:
1. HTTP (без S) — это протокол для обмена данными, который чаще всего используется между веб-браузером и веб-сайтом.
2. HTTPS — это защищённая версия этого протокола.
Почему HTTPS защищённый? Благодаря шифрованию.
Данные шифруются таким образом, что только веб-браузер и веб-сайт (сервер) знают, как их прочитать.
Без этого атаки типа «человек посередине» (MITM) могли бы перехватить ваш трафик и прочитать конфиденциальные данные, такие как пароли, данные кредитных карт и т. д.
Протокол, используемый для шифрования данных в HTTPS, — это TLS (Transport Layer Security):
💡 HTTPS = HTTP + TLS
HTTPS использует асимметричное шифрование для шифрования данных. У вас есть:
* 🔑 один закрытый ключ — секретный ключ SSL-сертификата веб-сайта, который никому не передаётся;
* 🔑 один открытый ключ — открытый ключ сертификата, который передаётся всем, кто хочет взаимодействовать с веб-сайтом.
💡 Асимметричное шифрование просто означает, что информация, зашифрованная открытым ключом, может быть расшифрована только закрытым ключом.
В отличие от этого, симметричное шифрование — это когда используется только один ключ, и данные могут быть зашифрованы/расшифрованы с помощью этого же ключа.
На самом деле HTTPS использует оба типа!
Асимметричное шифрование используется для проверки сервера и безопасного создания ключа сеанса. Ключ сеанса будет использоваться для симметричного шифрования.
Ключ сеанса, как следует из названия, существует только в течение сеанса и используется как клиентом, так и сервером для шифрования/дешифрования данных.
Самое интересное, что этот ключ детерминированно генерируется локально как клиентом, так и сервером независимо — он никогда не передаётся по сети.
Итак, какие шаги выполняются?
1. Клиент (браузер) подключается к серверу (веб-странице).
2. Сервер отправляет свой SSL-сертификат (включающий открытый ключ).
3. Клиент и сервер выполняют TLS-рукопожатие и генерируют ключ сеанса для шифрования/дешифрования будущих HTTP-данных.
4. Всё как обычно.
Подробности находятся в TLS-рукопожатии, и это, честно говоря, самая интересная часть работы HTTPS.
TLS-рукопожатие служит трём целям:
* 🔍 проверка подлинности сервера;
* ✨ генерация ключей сеанса для шифрования во время этого сеанса;
* 🤝 выбор версии TLS и наборов шифров, которые будут использоваться.
Пошагово (используя алгоритм TLS 1.2 RSA, потому что он проще):
1. Client Hello Request: клиент инициирует рукопожатие с сообщением, включающим версию TLS и поддерживаемые шифры, а также строку случайных байтов (называемую client random).
2. Server Hello Response: сервер выбирает набор шифров и генерирует свою строку случайных байтов (server random). Он отвечает с набором шифров, своим SSL-сертификатом и server random.
3. Client Verification: клиент проверяет сертификат через доверенный центр сертификации, который его выдал. SSL-сертификат имеет цифровую подпись, которая подписана закрытым ключом CA, поэтому клиент использует открытый ключ CA для её расшифровки.
После этого шага клиент проверил, что сертификат является легитимным и подтверждён через CA — не поддельным.
Примечание: он всё ещё не знает наверняка, действительно ли сервер владеет этим сертификатом (т. е. имеет закрытый ключ).
🤔 Кто определяет, какому центру сертификации можно доверять?
Компания, создавшая ваш браузер! Apple, Microsoft, Google, Mozilla и другие поддерживают свой список центров сертификации. Ваш браузер/ОС поставляется с этим списком доверенных центров сертификации.
Всё основано на доверии, так что лучше им доверять...
Продолжаем:
Прежде всего есть два протокола:
1. HTTP (без S) — это протокол для обмена данными, который чаще всего используется между веб-браузером и веб-сайтом.
2. HTTPS — это защищённая версия этого протокола.
Почему HTTPS защищённый? Благодаря шифрованию.
Данные шифруются таким образом, что только веб-браузер и веб-сайт (сервер) знают, как их прочитать.
Без этого атаки типа «человек посередине» (MITM) могли бы перехватить ваш трафик и прочитать конфиденциальные данные, такие как пароли, данные кредитных карт и т. д.
Протокол, используемый для шифрования данных в HTTPS, — это TLS (Transport Layer Security):
💡 HTTPS = HTTP + TLS
HTTPS использует асимметричное шифрование для шифрования данных. У вас есть:
* 🔑 один закрытый ключ — секретный ключ SSL-сертификата веб-сайта, который никому не передаётся;
* 🔑 один открытый ключ — открытый ключ сертификата, который передаётся всем, кто хочет взаимодействовать с веб-сайтом.
💡 Асимметричное шифрование просто означает, что информация, зашифрованная открытым ключом, может быть расшифрована только закрытым ключом.
В отличие от этого, симметричное шифрование — это когда используется только один ключ, и данные могут быть зашифрованы/расшифрованы с помощью этого же ключа.
На самом деле HTTPS использует оба типа!
Асимметричное шифрование используется для проверки сервера и безопасного создания ключа сеанса. Ключ сеанса будет использоваться для симметричного шифрования.
Ключ сеанса, как следует из названия, существует только в течение сеанса и используется как клиентом, так и сервером для шифрования/дешифрования данных.
Самое интересное, что этот ключ детерминированно генерируется локально как клиентом, так и сервером независимо — он никогда не передаётся по сети.
Итак, какие шаги выполняются?
1. Клиент (браузер) подключается к серверу (веб-странице).
2. Сервер отправляет свой SSL-сертификат (включающий открытый ключ).
3. Клиент и сервер выполняют TLS-рукопожатие и генерируют ключ сеанса для шифрования/дешифрования будущих HTTP-данных.
4. Всё как обычно.
Подробности находятся в TLS-рукопожатии, и это, честно говоря, самая интересная часть работы HTTPS.
TLS-рукопожатие служит трём целям:
* 🔍 проверка подлинности сервера;
* ✨ генерация ключей сеанса для шифрования во время этого сеанса;
* 🤝 выбор версии TLS и наборов шифров, которые будут использоваться.
Пошагово (используя алгоритм TLS 1.2 RSA, потому что он проще):
1. Client Hello Request: клиент инициирует рукопожатие с сообщением, включающим версию TLS и поддерживаемые шифры, а также строку случайных байтов (называемую client random).
2. Server Hello Response: сервер выбирает набор шифров и генерирует свою строку случайных байтов (server random). Он отвечает с набором шифров, своим SSL-сертификатом и server random.
3. Client Verification: клиент проверяет сертификат через доверенный центр сертификации, который его выдал. SSL-сертификат имеет цифровую подпись, которая подписана закрытым ключом CA, поэтому клиент использует открытый ключ CA для её расшифровки.
После этого шага клиент проверил, что сертификат является легитимным и подтверждён через CA — не поддельным.
Примечание: он всё ещё не знает наверняка, действительно ли сервер владеет этим сертификатом (т. е. имеет закрытый ключ).
🤔 Кто определяет, какому центру сертификации можно доверять?
Компания, создавшая ваш браузер! Apple, Microsoft, Google, Mozilla и другие поддерживают свой список центров сертификации. Ваш браузер/ОС поставляется с этим списком доверенных центров сертификации.
Всё основано на доверии, так что лучше им доверять...
Продолжаем:
- ❤ 10
- 🔥 1
- 👏 1
Post #1866
1.83K
Как работает HTTPS.
- 👍 1
Post #1864
2.38K
Команды Git по категориям #git
- 👍 21
- 🥴 4
- ❤ 3
- 👏 1
Post #1863
2.05K
Как работает MongoDB (описание к рисунку из предыдущего поста)
MongoDB была создана из необходимости: основатели столкнулись с проблемами при разработке масштабных веб-приложений с использованием существующих баз данных.
С ростом интернета, появлением всё более динамичных веб-сайтов и приложений, старые инструменты баз данных не справлялись с нагрузкой. MongoDB была разработана для заполнения этого пробела. Она предложила разработчикам гибкость, масштабируемость и простоту использования, необходимые для нового веба.
MongoDB в основном написана на C++, но использует JavaScript для своей оболочки и Python для некоторых инструментов и драйверов. В то время как традиционные реляционные базы данных хранят данные в таблицах и строках, MongoDB, по своей сути, — это NoSQL, документоориентированная база данных.
Но MongoDB:
* хранит данные во внутреннем бинарном формате, называемом BSON (Binary JSON).
* BSON — это расширенный набор JSON.
* Он может представлять всё, что может JSON, плюс дополнительные типы данных, такие как даты и двоичные данные.
* BSON более компактен, чем JSON, что уменьшает объём памяти и повышает производительность.
* Такая структура позволяет более естественно представлять реальные объекты и связи между ними.
Архитектура MongoDB
1. Document Model — гибкая модель хранения данных в формате JSON, позволяющая использовать различные структуры и вложенные объекты.
2. Collections — группы документов, аналогичные таблицам, но без строгой схемы, обеспечивающие гибкую организацию.
3. mongod — основной процесс, обрабатывающий хранение, запросы и администрирование.
4. mongos (если используется шардирование) — маршрутизирует запросы в распределённом кластере к правильным разделам данных.
5. Replica Sets — несколько узлов поддерживают копии данных, обеспечивая высокую доступность и отказоустойчивость.
6. Sharding — горизонтальное масштабирование путём распределения данных по нескольким серверам для больших наборов данных и высокой нагрузки.
7. Indexes — структуры данных для ускорения запросов, поддерживающие различные типы для разных шаблонов доступа.
8. WiredTiger — механизм хранения по умолчанию, оптимизированный для использования памяти и диска с контролем параллелизма.
9. Aggregation Framework — мощный конвейерный фреймворк для сложного анализа и преобразования данных.
10. Query Language — выразительный язык для фильтрации, сортировки, проецирования и агрегации данных.
Примеры использования
* Системы управления контентом
* Аналитика в реальном времени
* Интернет вещей (IoT)
* Мобильные приложения
* Каталоги товаров
Проблемы и ограничения
1. Транзакции — использует модель «snapshot isolation», что может иметь последствия для приложений, требующих строгих гарантий ACID.
2. Моделирование данных — гибкость требует продуманного проектирования.
3. Joins — MongoDB не поддерживает традиционные SQL-соединения.
4. Операционные затраты — MongoDB может требовать больше опыта в эксплуатации.
5. Стоимость — эксплуатация MongoDB может быть дорогой, особенно при масштабировании.
MongoDB была создана из необходимости: основатели столкнулись с проблемами при разработке масштабных веб-приложений с использованием существующих баз данных.
С ростом интернета, появлением всё более динамичных веб-сайтов и приложений, старые инструменты баз данных не справлялись с нагрузкой. MongoDB была разработана для заполнения этого пробела. Она предложила разработчикам гибкость, масштабируемость и простоту использования, необходимые для нового веба.
MongoDB в основном написана на C++, но использует JavaScript для своей оболочки и Python для некоторых инструментов и драйверов. В то время как традиционные реляционные базы данных хранят данные в таблицах и строках, MongoDB, по своей сути, — это NoSQL, документоориентированная база данных.
Но MongoDB:
* хранит данные во внутреннем бинарном формате, называемом BSON (Binary JSON).
* BSON — это расширенный набор JSON.
* Он может представлять всё, что может JSON, плюс дополнительные типы данных, такие как даты и двоичные данные.
* BSON более компактен, чем JSON, что уменьшает объём памяти и повышает производительность.
* Такая структура позволяет более естественно представлять реальные объекты и связи между ними.
Архитектура MongoDB
1. Document Model — гибкая модель хранения данных в формате JSON, позволяющая использовать различные структуры и вложенные объекты.
2. Collections — группы документов, аналогичные таблицам, но без строгой схемы, обеспечивающие гибкую организацию.
3. mongod — основной процесс, обрабатывающий хранение, запросы и администрирование.
4. mongos (если используется шардирование) — маршрутизирует запросы в распределённом кластере к правильным разделам данных.
5. Replica Sets — несколько узлов поддерживают копии данных, обеспечивая высокую доступность и отказоустойчивость.
6. Sharding — горизонтальное масштабирование путём распределения данных по нескольким серверам для больших наборов данных и высокой нагрузки.
7. Indexes — структуры данных для ускорения запросов, поддерживающие различные типы для разных шаблонов доступа.
8. WiredTiger — механизм хранения по умолчанию, оптимизированный для использования памяти и диска с контролем параллелизма.
9. Aggregation Framework — мощный конвейерный фреймворк для сложного анализа и преобразования данных.
10. Query Language — выразительный язык для фильтрации, сортировки, проецирования и агрегации данных.
Примеры использования
* Системы управления контентом
* Аналитика в реальном времени
* Интернет вещей (IoT)
* Мобильные приложения
* Каталоги товаров
Проблемы и ограничения
1. Транзакции — использует модель «snapshot isolation», что может иметь последствия для приложений, требующих строгих гарантий ACID.
2. Моделирование данных — гибкость требует продуманного проектирования.
3. Joins — MongoDB не поддерживает традиционные SQL-соединения.
4. Операционные затраты — MongoDB может требовать больше опыта в эксплуатации.
5. Стоимость — эксплуатация MongoDB может быть дорогой, особенно при масштабировании.
- 👍 12
- 🤔 2
- 🤮 2
- ❤ 1
- 🔥 1
Post #1862
1.94K
Как работает MongoDB
- 👍 1
Post #1861
2.14K
Вкратце как работает аутентификация через куки, сессии, токены, JWT, SSO и OAuth2
- 👍 17
- 🤔 4
- 🔥 2
- ❤ 1
Post #1859
2.06K
Исследователи из Microsoft изучили, какие профессии больше всего подвержены влиянию генеративного ИИ. Результаты исследования основаны исключительно на использовании Microsoft Copilot в США и могут не распространяться на другие платформы или страны.
Чтобы оценить влияние ИИ на разные профессии, исследователи разработали «показатель применимости ИИ», который учитывает частоту использования, процент успешных решений и то, насколько хорошо ИИ справляется с каждой задачей. Наивысшие баллы получили переводчики, историки, писатели, специалисты в области СМИ, консультанты по работе с клиентами и продавцы. Технические специалисты, такие как программисты ЧПУ и специалисты по обработке данных, также получили высокие оценки.
На другом конце шкалы находятся профессии, требующие физического труда, — сиделки, разнорабочие, уборщики и операторы станков, — на которые современные инструменты генеративного ИИ оказывают незначительное влияние. Исследование показало, что почти нет корреляции между тем, насколько ИИ подходит для той или иной работы, и уровнем заработной платы или образования. Хотя профессии, для которых требуется высшее образование, в меньшей степени подвержены влиянию искусственного интеллекта.
Наиболее распространённые задачи, решаемые с помощью ИИ, связаны со сбором информации, написанием и редактированием текстов, а также передачей идей. В этих областях ИИ показывает наилучшие результаты как с точки зрения удовлетворённости пользователей, так и с точки зрения скорости выполнения задач. Напротив, система менее эффективна при анализе данных или визуальном дизайне, а также с трудом справляется с задачами, требующими взаимодействия с реальным миром или физической работы, например с покупками или ремонтом.
Авторы предостерегают от поспешных выводов о том, что возможности ИИ автоматически приведут к автоматизации или сокращению рабочих мест. Во многих случаях ИИ выступает в роли помощника, поддерживая и улучшая работу людей, а не заменяя её. Они приводят в пример банкоматы в банковской сфере: автоматизация изменила подход к работе, но также создала новые рабочие места в отрасли.
https://the-decoder.com/microsoft-study-shows-these-professions-are-most-affected-by-generative-ai/
Чтобы оценить влияние ИИ на разные профессии, исследователи разработали «показатель применимости ИИ», который учитывает частоту использования, процент успешных решений и то, насколько хорошо ИИ справляется с каждой задачей. Наивысшие баллы получили переводчики, историки, писатели, специалисты в области СМИ, консультанты по работе с клиентами и продавцы. Технические специалисты, такие как программисты ЧПУ и специалисты по обработке данных, также получили высокие оценки.
На другом конце шкалы находятся профессии, требующие физического труда, — сиделки, разнорабочие, уборщики и операторы станков, — на которые современные инструменты генеративного ИИ оказывают незначительное влияние. Исследование показало, что почти нет корреляции между тем, насколько ИИ подходит для той или иной работы, и уровнем заработной платы или образования. Хотя профессии, для которых требуется высшее образование, в меньшей степени подвержены влиянию искусственного интеллекта.
Наиболее распространённые задачи, решаемые с помощью ИИ, связаны со сбором информации, написанием и редактированием текстов, а также передачей идей. В этих областях ИИ показывает наилучшие результаты как с точки зрения удовлетворённости пользователей, так и с точки зрения скорости выполнения задач. Напротив, система менее эффективна при анализе данных или визуальном дизайне, а также с трудом справляется с задачами, требующими взаимодействия с реальным миром или физической работы, например с покупками или ремонтом.
Авторы предостерегают от поспешных выводов о том, что возможности ИИ автоматически приведут к автоматизации или сокращению рабочих мест. Во многих случаях ИИ выступает в роли помощника, поддерживая и улучшая работу людей, а не заменяя её. Они приводят в пример банкоматы в банковской сфере: автоматизация изменила подход к работе, но также создала новые рабочие места в отрасли.
https://the-decoder.com/microsoft-study-shows-these-professions-are-most-affected-by-generative-ai/
- 👍 8
- 😁 5
- 🤮 4
- 🫡 3
Post #1858
2.17K
REST API vs GraphQL
- 🤷♂ 17
- 🔥 8
- 👌 4
Post #1857
2.27K
В ГосДуме призвали WhatsApp готовиться к уходу с российского рынка
Первый зампред Госдумы по информполитике Антон Горелкин считает, что мессенджер WhatsApp вскоре может попасть под ограничения.
По словам депутата, мессенджер может войти в список ПО из недружественных стран, который правительство разрабатывает по поручению президента России. Telegram ограничения не коснутся, но регистрация мессенджера на Виргинских островах вызывает вопросы, подчеркнул господин Горелкин.
Сейчас примерно 68% россиян пользуются WhatsApp ежедневно, около 55% заходят в Telegram, рассказал депутат, По его мнению, долю лидера в случае запрета может получить национальный мессенджер Max. Господин Горелкин ожидает, что в нем будут реализованы «уникальные функции».
Накануне Владимир Путин поручил правительству разработать ограничения для ПО, произведенного в недружественных странах. Доклад должен быть готов к 1 сентября.
https://www.kommersant.ru/doc/7897955
Первый зампред Госдумы по информполитике Антон Горелкин считает, что мессенджер WhatsApp вскоре может попасть под ограничения.
По словам депутата, мессенджер может войти в список ПО из недружественных стран, который правительство разрабатывает по поручению президента России. Telegram ограничения не коснутся, но регистрация мессенджера на Виргинских островах вызывает вопросы, подчеркнул господин Горелкин.
Сейчас примерно 68% россиян пользуются WhatsApp ежедневно, около 55% заходят в Telegram, рассказал депутат, По его мнению, долю лидера в случае запрета может получить национальный мессенджер Max. Господин Горелкин ожидает, что в нем будут реализованы «уникальные функции».
Накануне Владимир Путин поручил правительству разработать ограничения для ПО, произведенного в недружественных странах. Доклад должен быть готов к 1 сентября.
https://www.kommersant.ru/doc/7897955
- 🤡 53
- 👍 10
- 🤮 7
- 🤬 5
- 💩 5
- 👏 1
- 🥱 1
Post #1856
2K
Вкратце все версии Java/JDK #java
- 👍 15
Post #1855
2.07K
Количество вакансий для IT-специалистов начало сокращаться впервые за три года
Несмотря на импортозамещение и цифровизацию, число открытых вакансий для разработчиков софта в РФ впервые с 2022 года сократилось и составило, по данным HeadHunter за первое полугодие, 291 тыс. против свыше 300 тыс. год назад. Снижение числа объявлений о вакансиях для IT-специалистов заметили и в других кадровых агентствах.
По данным HeadHunter, на площадке количество размещенных объявлений снизилось за полугодие на 20%, до 220 тыс. вакансий. «Еще в прошлом году на рынке начала формироваться тенденция к сокращению персонала в крупных IT-компаниях, в том числе среди разработчиков, в пользу перераспределения нагрузки у тех, кто остается, и повышения их зарплат»,— говорит представитель HeadHunter. Однако, уточняет он, если на должности младших специалистов наблюдается профицит кадров (11,1 резюме на одну вакансию), то среди высококвалифицированных специалистов (senior) наблюдается дефицит — 2,3 резюме на одну вакансию.
Многие компании начали оптимизацию этого сегмента бизнеса, в том числе посредством сокращения дорогостоящих специалистов, объясняют участники рынка. Параллельно начинается процесс внедрения искусственного интеллекта в IT-сфере, что, по текущим оценкам, способно сэкономить до 30–50% бюджетов. Однако заменить разработчиков высокой квалификации ИИ не в состоянии, по крайней мере пока.
https://www.kommersant.ru/doc/7891622
Несмотря на импортозамещение и цифровизацию, число открытых вакансий для разработчиков софта в РФ впервые с 2022 года сократилось и составило, по данным HeadHunter за первое полугодие, 291 тыс. против свыше 300 тыс. год назад. Снижение числа объявлений о вакансиях для IT-специалистов заметили и в других кадровых агентствах.
По данным HeadHunter, на площадке количество размещенных объявлений снизилось за полугодие на 20%, до 220 тыс. вакансий. «Еще в прошлом году на рынке начала формироваться тенденция к сокращению персонала в крупных IT-компаниях, в том числе среди разработчиков, в пользу перераспределения нагрузки у тех, кто остается, и повышения их зарплат»,— говорит представитель HeadHunter. Однако, уточняет он, если на должности младших специалистов наблюдается профицит кадров (11,1 резюме на одну вакансию), то среди высококвалифицированных специалистов (senior) наблюдается дефицит — 2,3 резюме на одну вакансию.
Многие компании начали оптимизацию этого сегмента бизнеса, в том числе посредством сокращения дорогостоящих специалистов, объясняют участники рынка. Параллельно начинается процесс внедрения искусственного интеллекта в IT-сфере, что, по текущим оценкам, способно сэкономить до 30–50% бюджетов. Однако заменить разработчиков высокой квалификации ИИ не в состоянии, по крайней мере пока.
https://www.kommersant.ru/doc/7891622
- 😁 8
- 👍 3
- 🔥 2
- 🐳 2
- 👎 1
- 🤬 1