Комментарии

Итак, я сам пытался понять реальную разницу, когда дело доходит до NoSQL против RDBMS, и всегда получал ответ, который не совсем соответствовал этому. В моем поиске действительно есть 2 основных различия между NoSQL и SQL, и только 1 является истинным преимуществом.

ACID против BASE — NoSQL обычно не учитывает некоторые функции ACID SQL, своего рода «обманывая» его путь к повышению производительности, оставляя этот уровень абстракции программисту. Об этом уже говорилось в предыдущих постерах.

Горизонтальное масштабирование — Реальным преимуществом NoSQL является горизонтальное масштабирование, оно же сегментирование. Учитывая, что «документы» NoSQL являются своего рода «автономным» объектом, объекты могут находиться на разных серверах, не беспокоясь о соединении строк с нескольких серверов, как в случае с реляционной моделью.

Допустим, мы хотим вернуть объект, подобный этому:

post {
    id: 1
    title: 'My post'
    content: 'The content'
    comments: {
      comment: {
        id: 1
      }
      comment: {
        id: 2
      }
      ...
 
    views: {
      view: {
        user: 1
      }
      view: {
        user: 2
      }
      ...
    }
}

В NoSQL этот объект в основном хранится как есть и, следовательно, может находиться на одном сервере как своего рода автономный объект, без какой-либо необходимости объединяться с данными из других таблиц, которые могут находиться на других серверах БД.

Однако при использовании реляционных баз данных к сообщению необходимо будет присоединять комментарии из comments таблицы, а также представления из views таблицы. Это не было бы проблемой в SQL ~ ДО ~ тех пор, пока БД не будет разбита на сегменты, и в этом случае «комментарий 1» может находиться на одном сервере БД, а «комментарий 2» — на другом сервере БД. Это значительно затрудняет создание того же объекта в RDBMS, масштабируемой по горизонтали, чем в NoSQL DB.

Кто-нибудь из экспертов по БД подтвердит или оспорит эти тезисы?

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

Системы NoSQL используют разные компромиссы. Например, они не гарантируют, что второй сеанс сразу увидит данные, переданные первым сеансом. Тем самым отделяя транзакцию хранения некоторых данных от процесса предоставления этих данных каждому пользователю. Google «в конечном итоге согласован». Таким образом, одной транзакции не нужно ждать какого-либо (или гораздо меньшего) взаимодействия между узлами. Следовательно, они могут гораздо проще использовать большое количество узлов.

Почему NoSQL лучше «масштабируется», чем RDBMS?

Я прочитал следующий текст в DST клубе, в котором обсуждаются преимущества и недостатки NoSQL:

«В течение многих лет, чтобы повысить производительность серверов баз данных, администраторам баз данных приходилось покупать серверы большего размера по мере увеличения нагрузки на базу данных (масштабирование) вместо распределения базы данных по нескольким “хостам” по мере увеличения нагрузки (масштабирование). RDBMS обычно нелегко масштабируются, но новые базы данных NoSQL на самом деле рассчитаны на легкое расширение для использования преимуществ новых узлов и обычно разрабатываются с учетом недорогого стандартного оборудования.»

Я запутался в масштабируемости RDBMS и NoSQL.

Мое замешательство заключается в следующем:

— Почему RDBMS менее способны к масштабированию? И причина покупки серверов большего размера вместо покупки более дешевых.
— Почему NoSQL лучше поддается масштабированию?

Если уточнить и расширить список фреймворков для микросервисов:

1. Java

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Java:

— Spring Boot — Spring Boot — это популярный фреймворк микросервисов на Java. Позволяет создавать как небольшие, так и крупномасштабные приложения. Spring boot легко интегрируется с другими популярными фреймворками с помощью инверсии управления.

— Dropwizard — фреймворк Dropwizard используется для разработки удобных, высокопроизводительных и Restful веб-сервисов. Без дополнительных настроек поддерживает инструменты конфигурации, метрики приложения, протоколирования и работы.

— Restlet — фреймворк Restlet следует архитектурному стилю RST, который помогает Java-разработчикам создавать микросервисы. Принят и поддерживается Apache Software License.

— Helidon — Коллекция библиотек Java для написания микросервисов. Простой в использовании, с инструментальными возможностями, поддержкой микропрофилей, реактивным веб-сервером, наблюдаемый и отказоустойчивый.

— AxonIQ — Событийно-ориентированный фреймворк микросервисов с открытым исходным кодом, сфокусированный на Command Query Responsibility Segregation (CQRS), Domain-Driven Design (DDD) и скоринге событий.

— Micronaut — full-stack фреймворк на основе JVM для построения модульных, легко тестируемых микросервисных и бессерверных приложений. Создает полнофункциональные микросервисы, включая внедрение зависимостей, автоконфигурацию, обнаружение служб, маршрутизацию HTTP и клиент HTTP. Micronaut стремится избежать недостатков фреймворков Spring, Spring Boot, обеспечивая более быстрое время запуска, уменьшение объема памяти, минимальное использование рефлексии и спокойное юнит-тестирование.

— Lagom — Реактивный фреймворк микросервисов с открытым исходным кодом для Java или Scala. Lagom базируется на Akka и Play.

2. GoLang

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Go

— GoMicro — подключаемая библиотека RPC предоставляет фундаментальные строительные блоки для написания микросервисов на языке Go. Поддерживаются API-шлюз, интерактивный CLI, сервисный прокси, шаблоны и веб-панели.

3. Python

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Python:

— Flask — Web Server Gateway Interface (WSGI) Веб-ориентированный легкий фреймворк микросервисов на языке Python. Flask-RESTPlus — расширение для Flask, которое предоставляет поддержку для быстрого создания REST API.

— Falcon — веб-фреймворк API для построения надежных бэкендов приложений и микросервисов в Python. Фреймворк отлично работает как с асинхронным интерфейсом шлюза сервера (ASGI), так и с WSGI.

— Bottle — Быстрый, легкий и простой WSGI микросервисный веб-фреймворк на основе Python. Распространяется одним файловым модулем и не имеет зависимостей, кроме стандартной библиотеки Python.

— Nameko — Фреймворк Nameko для построения микросервисов на Python со встроенной поддержкой RPC через AMQP, асинхронных событий, HTTP GET и POST, а также WebSocket RPC.

— CherryPy — CherryPy позволяет разработчикам создавать веб-приложения, используя объектно-ориентированное программирование на Python.

4. NodeJS

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языков программирования NodeJS

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

5. .NET

ASP.Net, фреймворк, используемый для веб-разработки и делающий ее API. Микросервисы поддерживают встроенные функции, для их (микросервисов) построения и развертывания с помощью контейнеров Docker.

6. MultiLanguage

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием нескольких языков

— Spark — создание веб-приложений микросервисов с использованием Kotlin и Java. Выразительный и простой веб-фреймворк DSL на Java/Kotlin, созданный для быстрой разработки.

Если уточнить и расширить список фреймворков для микросервисов:

1. Java

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Java:

— Spring Boot — Spring Boot — это популярный фреймворк микросервисов на Java. Позволяет создавать как небольшие, так и крупномасштабные приложения. Spring boot легко интегрируется с другими популярными фреймворками с помощью инверсии управления.

— Dropwizard — фреймворк Dropwizard используется для разработки удобных, высокопроизводительных и Restful веб-сервисов. Без дополнительных настроек поддерживает инструменты конфигурации, метрики приложения, протоколирования и работы.

— Restlet — фреймворк Restlet следует архитектурному стилю RST, который помогает Java-разработчикам создавать микросервисы. Принят и поддерживается Apache Software License.

— Helidon — Коллекция библиотек Java для написания микросервисов. Простой в использовании, с инструментальными возможностями, поддержкой микропрофилей, реактивным веб-сервером, наблюдаемый и отказоустойчивый.

— AxonIQ — Событийно-ориентированный фреймворк микросервисов с открытым исходным кодом, сфокусированный на Command Query Responsibility Segregation (CQRS), Domain-Driven Design (DDD) и скоринге событий.

— Micronaut — full-stack фреймворк на основе JVM для построения модульных, легко тестируемых микросервисных и бессерверных приложений. Создает полнофункциональные микросервисы, включая внедрение зависимостей, автоконфигурацию, обнаружение служб, маршрутизацию HTTP и клиент HTTP. Micronaut стремится избежать недостатков фреймворков Spring, Spring Boot, обеспечивая более быстрое время запуска, уменьшение объема памяти, минимальное использование рефлексии и спокойное юнит-тестирование.

— Lagom — Реактивный фреймворк микросервисов с открытым исходным кодом для Java или Scala. Lagom базируется на Akka и Play.

2. GoLang

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Go

— GoMicro — подключаемая библиотека RPC предоставляет фундаментальные строительные блоки для написания микросервисов на языке Go. Поддерживаются API-шлюз, интерактивный CLI, сервисный прокси, шаблоны и веб-панели.

3. Python

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Python:

— Flask — Web Server Gateway Interface (WSGI) Веб-ориентированный легкий фреймворк микросервисов на языке Python. Flask-RESTPlus — расширение для Flask, которое предоставляет поддержку для быстрого создания REST API.

— Falcon — веб-фреймворк API для построения надежных бэкендов приложений и микросервисов в Python. Фреймворк отлично работает как с асинхронным интерфейсом шлюза сервера (ASGI), так и с WSGI.

— Bottle — Быстрый, легкий и простой WSGI микросервисный веб-фреймворк на основе Python. Распространяется одним файловым модулем и не имеет зависимостей, кроме стандартной библиотеки Python.

— Nameko — Фреймворк Nameko для построения микросервисов на Python со встроенной поддержкой RPC через AMQP, асинхронных событий, HTTP GET и POST, а также WebSocket RPC.

— CherryPy — CherryPy позволяет разработчикам создавать веб-приложения, используя объектно-ориентированное программирование на Python.

4. NodeJS

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языков программирования NodeJS

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

5. .NET

ASP.Net, фреймворк, используемый для веб-разработки и делающий ее API. Микросервисы поддерживают встроенные функции, для их (микросервисов) построения и развертывания с помощью контейнеров Docker.

6. MultiLanguage

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием нескольких языков

— Spark — создание веб-приложений микросервисов с использованием Kotlin и Java. Выразительный и простой веб-фреймворк DSL на Java/Kotlin, созданный для быстрой разработки.

Если уточнить и расширить список фреймворков для микросервисов:

1. Java

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Java:

— Spring Boot — Spring Boot — это популярный фреймворк микросервисов на Java. Позволяет создавать как небольшие, так и крупномасштабные приложения. Spring boot легко интегрируется с другими популярными фреймворками с помощью инверсии управления.

— Dropwizard — фреймворк Dropwizard используется для разработки удобных, высокопроизводительных и Restful веб-сервисов. Без дополнительных настроек поддерживает инструменты конфигурации, метрики приложения, протоколирования и работы.

— Restlet — фреймворк Restlet следует архитектурному стилю RST, который помогает Java-разработчикам создавать микросервисы. Принят и поддерживается Apache Software License.

— Helidon — Коллекция библиотек Java для написания микросервисов. Простой в использовании, с инструментальными возможностями, поддержкой микропрофилей, реактивным веб-сервером, наблюдаемый и отказоустойчивый.

— AxonIQ — Событийно-ориентированный фреймворк микросервисов с открытым исходным кодом, сфокусированный на Command Query Responsibility Segregation (CQRS), Domain-Driven Design (DDD) и скоринге событий.

— Micronaut — full-stack фреймворк на основе JVM для построения модульных, легко тестируемых микросервисных и бессерверных приложений. Создает полнофункциональные микросервисы, включая внедрение зависимостей, автоконфигурацию, обнаружение служб, маршрутизацию HTTP и клиент HTTP. Micronaut стремится избежать недостатков фреймворков Spring, Spring Boot, обеспечивая более быстрое время запуска, уменьшение объема памяти, минимальное использование рефлексии и спокойное юнит-тестирование.

— Lagom — Реактивный фреймворк микросервисов с открытым исходным кодом для Java или Scala. Lagom базируется на Akka и Play.

2. GoLang

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Go

— GoMicro — подключаемая библиотека RPC предоставляет фундаментальные строительные блоки для написания микросервисов на языке Go. Поддерживаются API-шлюз, интерактивный CLI, сервисный прокси, шаблоны и веб-панели.

3. Python

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Python:

— Flask — Web Server Gateway Interface (WSGI) Веб-ориентированный легкий фреймворк микросервисов на языке Python. Flask-RESTPlus — расширение для Flask, которое предоставляет поддержку для быстрого создания REST API.

— Falcon — веб-фреймворк API для построения надежных бэкендов приложений и микросервисов в Python. Фреймворк отлично работает как с асинхронным интерфейсом шлюза сервера (ASGI), так и с WSGI.

— Bottle — Быстрый, легкий и простой WSGI микросервисный веб-фреймворк на основе Python. Распространяется одним файловым модулем и не имеет зависимостей, кроме стандартной библиотеки Python.

— Nameko — Фреймворк Nameko для построения микросервисов на Python со встроенной поддержкой RPC через AMQP, асинхронных событий, HTTP GET и POST, а также WebSocket RPC.

— CherryPy — CherryPy позволяет разработчикам создавать веб-приложения, используя объектно-ориентированное программирование на Python.

4. NodeJS

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языков программирования NodeJS

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

5. .NET

ASP.Net, фреймворк, используемый для веб-разработки и делающий ее API. Микросервисы поддерживают встроенные функции, для их (микросервисов) построения и развертывания с помощью контейнеров Docker.

6. MultiLanguage

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием нескольких языков

— Spark — создание веб-приложений микросервисов с использованием Kotlin и Java. Выразительный и простой веб-фреймворк DSL на Java/Kotlin, созданный для быстрой разработки.

Если уточнить и расширить список фреймворков для микросервисов:

1. Java

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Java:

— Spring Boot — Spring Boot — это популярный фреймворк микросервисов на Java. Позволяет создавать как небольшие, так и крупномасштабные приложения. Spring boot легко интегрируется с другими популярными фреймворками с помощью инверсии управления.

— Dropwizard — фреймворк Dropwizard используется для разработки удобных, высокопроизводительных и Restful веб-сервисов. Без дополнительных настроек поддерживает инструменты конфигурации, метрики приложения, протоколирования и работы.

— Restlet — фреймворк Restlet следует архитектурному стилю RST, который помогает Java-разработчикам создавать микросервисы. Принят и поддерживается Apache Software License.

— Helidon — Коллекция библиотек Java для написания микросервисов. Простой в использовании, с инструментальными возможностями, поддержкой микропрофилей, реактивным веб-сервером, наблюдаемый и отказоустойчивый.

— AxonIQ — Событийно-ориентированный фреймворк микросервисов с открытым исходным кодом, сфокусированный на Command Query Responsibility Segregation (CQRS), Domain-Driven Design (DDD) и скоринге событий.

— Micronaut — full-stack фреймворк на основе JVM для построения модульных, легко тестируемых микросервисных и бессерверных приложений. Создает полнофункциональные микросервисы, включая внедрение зависимостей, автоконфигурацию, обнаружение служб, маршрутизацию HTTP и клиент HTTP. Micronaut стремится избежать недостатков фреймворков Spring, Spring Boot, обеспечивая более быстрое время запуска, уменьшение объема памяти, минимальное использование рефлексии и спокойное юнит-тестирование.

— Lagom — Реактивный фреймворк микросервисов с открытым исходным кодом для Java или Scala. Lagom базируется на Akka и Play.

2. GoLang

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Go

— GoMicro — подключаемая библиотека RPC предоставляет фундаментальные строительные блоки для написания микросервисов на языке Go. Поддерживаются API-шлюз, интерактивный CLI, сервисный прокси, шаблоны и веб-панели.

3. Python

Доступно несколько фреймворков для разработки архитектуры микросервисов с использованием языка программирования Python:

— Flask — Web Server Gateway Interface (WSGI) Веб-ориентированный легкий фреймворк микросервисов на языке Python. Flask-RESTPlus — расширение для Flask, которое предоставляет поддержку для быстрого создания REST API.

— Falcon — веб-фреймворк API для построения надежных бэкендов приложений и микросервисов в Python. Фреймворк отлично работает как с асинхронным интерфейсом шлюза сервера (ASGI), так и с WSGI.

— Bottle — Быстрый, легкий и простой WSGI микросервисный веб-фреймворк на основе Python. Распространяется одним файловым модулем и не имеет зависимостей, кроме стандартной библиотеки Python.

— Nameko — Фреймворк Nameko для построения микросервисов на Python со встроенной поддержкой RPC через AMQP, асинхронных событий, HTTP GET и POST, а также WebSocket RPC.

— CherryPy — CherryPy позволяет разработчикам создавать веб-приложения, используя объектно-ориентированное программирование на Python.

4. NodeJS

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием языков программирования NodeJS

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

5. .NET

ASP.Net, фреймворк, используемый для веб-разработки и делающий ее API. Микросервисы поддерживают встроенные функции, для их (микросервисов) построения и развертывания с помощью контейнеров Docker.

6. MultiLanguage

Существует несколько фреймворков для разработки архитектуры микросервисов с использованием нескольких языков

— Spark — создание веб-приложений микросервисов с использованием Kotlin и Java. Выразительный и простой веб-фреймворк DSL на Java/Kotlin, созданный для быстрой разработки.

У Java есть отличные пара фреймворков (vertx.io и quarkus который базируется на первом) и они более популярны чем тот же упомянутый Micronaut. Так же у Java ничего не говорится про поддержку GraalVM, а именно здесь основная битва происходит у современных Java фреймворков.

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

Один из ярких примеров успешного масштабирования приложений – это разработка и запуск мобильного приложения «Яндекс.Такси». Это приложение было создано в 2011 году и с тех пор стало одним из самых популярных и удобных способов вызова такси в России. Благодаря высокому качеству сервиса и удобству использования, «Яндекс.Такси» быстро завоевало доверие пользователей и стало популярным не только в России, но и за ее пределами. Сегодня это приложение предоставляет свои услуги в нескольких странах и активно развивается, привлекая все больше пользователей.

Еще одним примером успешного масштабирования приложений является разработка и запуск мессенджера «Telegram». Это приложение было создано в 2013 году и с тех пор стало одним из самых популярных и безопасных способов общения в мире. Благодаря своей простоте, надежности и высокому уровню защиты данных, «Telegram» привлек миллионы пользователей со всего мира. Команда разработчиков «Telegram» активно работает над улучшением функционала и расширением возможностей приложения, что позволяет ему успешно масштабироваться и привлекать все больше пользователей.

Еще одним примером успешного масштабирования приложений является разработка и запуск онлайн-сервиса «Delivery Club». Этот сервис был создан в 2009 году и стал одним из самых популярных способов заказа еды с доставкой. Благодаря широкой сети партнеров и удобному интерфейсу, «Delivery Club» быстро завоевал популярность среди пользователей и начал активно развиваться. Сегодня этот сервис предоставляет свои услуги во многих городах России и активно расширяется за ее пределами.

Еще одним примером успешного масштабирования приложений является разработка и запуск онлайн-платформы «Wildberries». Эта платформа была создана в 2004 году и стала одной из крупнейших интернет-магазинов в России и СНГ. Благодаря широкому ассортименту товаров, удобному интерфейсу и быстрой доставке, «Wildberries» завоевал доверие миллионов пользователей и стал популярным не только в России, но и за ее пределами. Сегодня платформа «Wildberries» успешно масштабируется и продолжает привлекать все больше клиентов, предлагая им широкий выбор товаров и удобные условия покупки.

Ключевые факторы, влияющие на производительность и масштабируемость

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

— Проектирование программного обеспечения. Правильная разработка программного обеспечения имеет решающее значение для достижения масштабируемости и производительности. Такие методы, как модульность, развязка и разделение задач, могут помочь создать более удобные в обслуживании и масштабируемые приложения.
— Хранение и извлечение данных. Эффективная обработка данных необходима для масштабируемого программного обеспечения. Различные системы хранения, такие как реляционные базы данных, базы данных NoSQL и механизмы кэширования, могут использоваться для оптимизации операций хранения и извлечения данных.
— Сети. Задержка, пропускная способность и надежность сети существенно влияют на производительность программного обеспечения. Использование соответствующих сетевых протоколов, алгоритмов сжатия и сетей доставки контента (CDN) может помочь устранить узкие места сети и повысить производительность.
— Аппаратное обеспечение. Базовое оборудование, на котором работает программное обеспечение, включая серверы, хранилища и сетевые устройства, может ограничивать производительность и масштабируемость. Регулярные обновления оборудования и стратегии эффективного использования ресурсов могут помочь решить эти проблемы.
— Шаблоны пользователей: прогнозирование поведения пользователей и соответствующая разработка программного обеспечения могут значительно повысить производительность. Анализ пользовательских шаблонов для выявления часто используемых функций, пикового времени использования и распространенных узких мест может помочь в оптимизации программного обеспечения.

У вас задача, которая решается с помощью OLAP.
Поэтому копать нужно в эту сторону, решений достаточно много.

Партицируйте прямо по суткам.

Убирайте транзакции, нафиг вам тут innodb когда хватит myisam, оно на запись быстрее, у вас база write once read… тоже once.

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

На время обработки аналитики можно потюнить файловую систему и отключить flush для файлов таблиц (например ext4 data writeback и можно отключить журнал) — сильно ускоряет именно запись, особенно если много ram, это включает большой риск потери/порчи данных при сбросе ос но с другой стороны вероятность этого очень мала и как я понимаю, данные в базу и так пишутся из какого то другого хранилища, т.е. при проблеме с сервером просто перезапускается обработка за текущие сутки.

Уберите индексы на запись, все, сначала пусть идет вставка данных без их индексации, затем создаете индекс (это на порядок быстрее) и уже потом строите аналитику.

Общая аналитика должна не работать с самими данными, а с их посуточной выжимкой (возможно в результате и хранить их не придется) считай это самодельные индексы. Грубо говоря если в запросе на аналитику стоит count,max,min,… то достаточно сложить посуточные значения и для глобальных считать уже по ним… само собой если запросы с условиями и сложными группировками, то надо думать но все решаемо… грубый пример нужно считать агрегацию по часам, вот в индексы и пиши суточные значения по часам, а если надо постранично то для каждой страницы для каждых суток считаешь, потом агрегируешь уже по этим результатам.

Порекомендуйте подходящую базу данных?
День добрый.

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

Дано
Имеется некая аналитическая система которая работает на нескольких сайтах. Она для каждой страницы, для каждого элемента сохраняет некую статистику (к примеру, сколько раз элемент был виден, сколько раз на него кликнули и т.д., но в целом это не так важно). Все данные аггрегируются в памяти, а затем раз в сутки скидываются в табличку в БД. Затем аналитики могут генерировать отчет за определенный период для определенного сайта + определенной страницы + определенного сегмента. Либо за определенный период для определенного сайта + определенной страницы + отдельного элемента.

Структура таблицы примерно такая:
1. ID сайта
2. ID страницы
3. ID елемента
4. Дата (день)
5. ID сегмента пользователя (все пользователи поделены на некое количество разных сегментов)
6+. Все остальные поля с данными

На данный момент мы используем Amazon Aurora (MySQL 5.7) с движком InnoDB
Поля с 1-5 это первичный ключ.
Ежедневно в таблицу записывается порядка 80М строчек (но это не конечная цель, в будущем возможна запись и намного большего количества)
Запись оптимизированна и происходит блоками по 1000 строчек в каждом INSERT запросе.

Проблемы текущего подхода
1. Когда таблица пустая, то запись такого количества данных занимает несколько часов, но уже через месяц, из-за увеличения индекса, скорость падает до примерно 12 часов. Т.е. если данных будет в 2 раза больше, то уже не получится вложиться в 24 часовое окно, когда еще не закончилась запись предыдущего дня, а надо уже писать следующий.
2. Скорость генерации отчет оставляет желать лучшего. Для страницы с большим количеством элементов, генерация репорта за месяц может занимать 2-3 минуты, это слишком долго.
3. Иногда нужно удалить данные для определенного сайта, изза огромного количества данных такая процедура блокирует не только саму таблицу, но и всю БД, в которой еще много других таблиц к которым постоянно идет обращение чтение/запись. Пытались решить данную проблему партицированием, но это не особо помогло.

Какие будут предложения?

Serverless — это очень урезанный docker контейнер со своим API и временем жизни до 5 минут. При этом 1 контейнер обслуживает 1 запрос. В течении 5 минут после исполнения контейнер остается «горячим», т.е. содержит все данные после прошлого исполнения. Соответственно, если у вас память течет, то под нагрузкой память освобождаться не будет, т.к. контейнеры переиспользуются.

Кроме того, если вы хотите обслуживать внешние запросы, то нужно еще использовать прокладку в виде api gateway (за это тоже нужно платить).

Мороки с настройками тоже свои есть. Мониторить лямбды тоже задача со своими нюансами. Если у вас просто сайт/api и более-менее регулярная загрузка есть, то я бы serverless не советовал. Elastic beanstalk на самом деле удобнее и практичнее. А вот для задач вроде selenium тестирования, когда нужно 1000 тестов параллельно запустить и потом до следующего билда вам мощности не нужны — serverless это очень хорошо.

Начну с того, что если вы таки активный разработчик и не очень можете понять этот принцип, возможно он вам просто не нужен. И это не значит что вы плохой разработчик, просто не пересекались с таким видом проблем.
Что касается serverless, название больше отражает не факт отсутствия сервера и работы с ним как таковым, а скорее еще меньше возни с настройкой и поддержкой серверного окружения (даже меньше чем с докером после того как все настроено и поднято). Те это следующие шаг после условных микросервисов.
Его часто удобнее называть функция как услуга, так как де факто часто реализуется запуск именно функции по запросу.
Если кратко описать для чего это нужно, то представим себе что у нас есть микросервис у которого затраты на содержания его постоянного аптайма как то слишком велики относительно времени работы/потребления ресурсов в живую. Да и в целом сервис выходит как то слишком микро даже для микросервиса.
Вот тут мы и придумываем такую штуку, которая будет ОЧЕНЬ быстро(относительно старта минимальной виртуалки/образа и чего другого) запускаться, быстро делает свою маленькую работу и выключается.
Из ключевых особенностей отмечу что функции должно быть в целом пофиг на своего состояние, она не знает изначально о предыдущем запуске и тп(те быть stateless). Все что нужно приходит в запросе.
Ври значит если у вас есть задача, которая удовлетворяет этим условиям, можно использовать этот удобный сервис и для масштабируемости, и для экономии и для кучи других фич.
Примеры:
ресайз изображений.
Генератор статистических сайтов(через админку производим обновление статистических файлов, это бывает не часто).
Чат боты
Разные спец информеры с определенной логикой.
И тд и тп, что хорошо ложится в определенную относительно простую функцию с простым входом данных(или без) и простым результатом работы.
В целом это решение не панацея, более того нужно четко понимать насколько выгодно/невыгодно переделывать на серверлесс платформы свою функцию, ведь мы точно жертвуем той же производительностью(помним что сервис не висит и не ждет нас постоянно, а пусть и очень быстро, но запускается), понижается прозрачность исполнения и усложняется отладка и прочее.
Но в любом случае, достаточно часто плюсы перебивают минусы, популярность у этого принципа есть. люди активно пользуются, так что много шишок уже набито, в целом зрелая штука.
А и да, насчет конкретного вашего вопроса.
PHP AWS Lambda нативно не поддерживает, все через костыли, впрочем с почти вменяемой производительностью.
И так как все таки AWS Lambda все же ближе к самому популярному нынче принципу serverless — функция как сервис, я не уверен что это правильная идея будет запускать атм Ларавел.
Те мы имеем минусы: отсутствие нативной поддержки PHP и такие заточенность под что-то простое, в итоге… ну не знаю.
Я думаю плюшки serverless в виде нет мороки с настройкой сервера/облака можно решить многими другими сервисами. Впрочем может быть это будет не так выгодно в вашем случае, нужно исходить и рассчитывать по вашему сценарию работы вашего приложения. А потом решать, что лучше подходит.

В чем суть serverless подхода?
В общем недавно Lambda выкатила поддержку PHP, что довольно радостно.
Но у меня возникли некоторые вопросы по архитектуре проектов с ее использованием.

В контенксте Lambda+PHP я вижу следующие варианты использования:
1. Реализация микросервисной архитектуры ( где каждый микросервис выступает функцией)
2. Реализация монолитной архитектуры ( например закинуть монолитный Laravel как одну функцию )

На сколько этот подход оптимальный/верный/логичный в контексте serverless и AWS Lambda в часности?

1) data-only containers
2) решите задачу подъема самого сервера с запущенным Docker, в контейнерах задаете политику всегда перезапускаться — они вместе с самим Docker запустятся
3) в идеале по контейнеру на процесс либо логическую часть, к примеру MariaDB это один, Python сервер это второй и так далее
4) внимательно изучать внутренности, кроме официальных выбирать только те, которые имеют автоматические билды с отрытым Dockerfile и поддерживаются актуальными, иногда придется делать свои
5) ответ тот же что и 1) + резервное копирование/восстановление из томов
6) не встраивайте чувствительные данные в образы и не попадут

В качестве неплохого примера можете посмотреть мою разработку (правда, ориентирована на PHP, но суть та же, посмотрите как устроено

Вы читали кучу мануалов, но упустили самое главное — официальная документация. Как так? Там как раз и говорится как делать и почему. На вопросы уже поотвечали, но пройдусь ещё раз, раз столько времени на чтение ответов потратил :>
1) docs.docker.com/engine/userguide/dockervolumes/
2) docs.docker.com/engine/articles/host_integ…
3) Ответ простой — как хотите. Как лучше знаете только вы, звучит банально, но это так. Хотите хоть всё в один контейнер запихните, это ваше дело. Хотя рекомендуют 1 компонент на 1 контейнер. В этом есть своя логика — хочется обновить только mysql — обновляете этот контейнер и не думаете, поломался ли у вас uwsgi или nginx или ещё чего.
4) Напишите свой первый Dockerfile, станет куда яснее как выбирать. А пока доверяйте только официальным образам.
5) git? Этот вопрос — следствие непонимания вопроса 1)
6) Уже ответили. Самое простое, если не понимаете — не используйте dockerhub вообще. Или начните понимать. Или платите за приватные репозитории, чтобы не думать об этом.

Уважаемые девопсы и системные администраторы, нужна ваша помощь в понимании как работает и как настраивать Docker.

Например, моя ситуация: VDS c Debian, нужно поставить внутри MySQL(MariaDB), Python/Django, Nginx, Memcached, Sphinx Search.

Задачи, которую я хочу решить Докером:

— разграничения по ресурсам некоторых особо прожорливых компонентов (швыряю булыжник в окно MySQL)
— возможность немного поэксперементировать с версиями и настройками компонентов
— если что-то не устроит на хостинге — взял свои контейнеры и пошел на другой

За последние дни я прочитал кучу мануалов и объяснений зачем, и как работает докер, кучу примеров по разработке приложений, но вот моего юзкейса в чистом виде, решения моих задач я не нашел — только намеки, полунамеки и скупые строчки, что да, вот так вот сделать можно, но ничего подробного, исчерпывающего для понимания и уж тем более никаких инструкций такого плана: отсюда бери — туда клади, тут запускай эту команду, потому что…

Основные вопросы, которые у меня остались:
1) т/к контейнеры стейтлес, а мне нужно все же хранить и создавать данные, как создавать, записывать и хранить изменения?
2) как автоматически стартовать контейнеры с изменениями, если какой-то пьяный дебил перерубил лопатой провод из ДЦ и все потухло? Т/е как стейтлес контейнеры превратить в стейтфул простыми способами. Т/е сервер падает, поднимается и все работает с того места где он упал.
3) Как лучше разбить на контейнеры мою обвязку сервера?
4) Как выбирать необходимые контейнеры приложений на Докерхабе?
5) Как и где хранить данные (например проекты Django), чтобы их не потерять, но вместе с тем удобно мигрировать на другой хост в случае чего
6) Из-за недопонинимания как все работает: как (и возможно ли вообще такое) не допустить утечки каких-либо чувствительных данных в докерхаб вместе с образом какого-нибудь моего контейнера?

Звучит как обычный таск-трекер. Если таски правильно сформулированы и оформлены — то все там можно будет найти.

1. Формировать задачи в трекере, например gitlab
2. Использовать релизы
3. С выходом релиза фиксировать задачи/фикс багов, релиза в CHANGELOG.md