Последние сообщения

Еще бы рассказали как правильно подбирать технологии для проекта?

Некоторые технологии, которые стоит использовать для создания высокоскоростных веб-страниц:

— Асинхронная загрузка. Позволяет отображать страницу, пока остальные ресурсы загружаются на заднем плане.

— Lazy loading («ленивая загрузка»). Загружает изображения, видео и другие тяжёлые элементы только тогда, когда они становятся видимыми пользователю. Например, изображения на длинной странице блога загружаются только при прокрутке вниз.

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

— Сжатие данных. Для этого используется сжатие текстовых файлов (HTML, CSS, JavaScript) с помощью алгоритмов, таких как Gzip или Brotli.

— Ускоренные мобильные страницы (AMP). Загружают мобильные страницы быстрее по сравнению с HTML и показывают только наиболее приоритетные данные (текстовый контент, картинки).

Выбор технологий зависит от конкретных требований проекта.

Начиная с MySQL 5.5.3 вы должны использовать utf8mb4, а не utf8. Обе эти группы относятся к кодировке UTF-8, но более старая utf8 имеет специфичные для MySQL ограничения, не дающие использовать символы, пронумерованные выше 0xFFFD.

Таким образом, больше не нужно использовать ни utf8_general_ci, ни utf8_unicode_ci.

Что касается новых версий кодировки utf8mb4_general_ci и utf8mb4_unicode_ci. То предпочтительной является unicode, а не general. Вариант utf8mb4_general_ci будет чуть более быстрым при сортировке (в настоящее время это уже неактуально), но имеет проблемы с сортировкой в определённых языках. Кодировка utf8mb4_unicode_ci лишена этих недостатков.

Совет: для сохранения места с utf8mb4, используйте VARCHAR вместо CHAR. В противном случае MySQL будет резервировать четыре байта для каждого символа в стобце CHAR CHARACTER SET utf8mb4, поскольку это максимально возможная длина. Например, MySQL должна зарезервировать 40 байт для столбца CHAR(10) CHARACTER SET utf8mb4.

Примечание: точнее utf8mb4_unicode_ci не совсем кодировка, в терминах MySQL это называется COLLATION («сравнение») и включает в себя набор символов, а также правила сравнения и сортировки. То есть utf8mb4_unicode_ci это COLLATION, а utf8mb4 это набор символов, а UTF-8 это уже и есть кодировка переменной длины.

Для нового проекта рекомендуется использовать кодировку utf8mb4_unicode_ci. Эта кодировка обеспечивает поддержку большего количества символов и считается более современной.

В обновлении для второй ветки уже вышло, так что просто обновите свою лицензию и все

Ничего сложного не вижу. Чтобы подключить оплату криптовалютой к DST Marketplace, вам нужно выполнить следующие шаги:

1. Выберите платёжный шлюз криптовалют, поддерживающий нужные криптовалюты и обеспечивающий безопасность транзакций.

2. Интегрируйте выбранный платёжный шлюз с вашим сайтом или платформой, обеспечивая возможность оплаты в криптовалютах.

3. Обучите персонал и клиентов работе с криптовалютными платежами, предоставив информацию о преимуществах и методах оплаты.

4. Обеспечьте безопасность и конфиденциальность приёма криптовалютных платежей, применяя меры защиты данных и транзакций.

5. Отслеживайте и анализируйте криптовалютные транзакции для оптимизации процесса оплаты и понимания потребительского поведения.

Вот и вообщем то все.

Чтобы организовать надёжную инфраструктуру для веб-проекта с использованием PHP Yii2, MySQL и Vue.js SPA, следуйте этим рекомендациям:

1. Выберите надёжного хостинг-провайдера с хорошей репутацией и поддержкой PHP, MySQL и Vue.js.

2. Используйте систему контроля версий, например Git, для управления исходным кодом вашего проекта.

3. Установите и настройте PHP, MySQL и Node.js на сервере.

4. Создайте виртуальное окружение для Vue.js и установите необходимые зависимости.

5. Разделите проект на несколько файлов и папок, следуя структуре проекта Yii2.

6. Настройте базу данных MySQL и создайте таблицы для хранения данных вашего проекта.

7. Установите и настройте Nginx или Apache в качестве веб-сервера.

8. Настройте виртуальные хосты для вашего проекта и укажите правильный путь к файлам проекта.

9. Запустите проект с помощью команды `php yii serve`.

10. Добавьте Vue.js SPA в ваш проект, используя инструкции из документации Vue.js.

11. Настройте маршрутизацию и представление вашего приложения с помощью Vue.js.

12. Внедрите аутентификацию и авторизацию пользователей с использованием Yii2 и MySQL.

13. Обеспечьте безопасность вашего проекта, настроив защиту от XSS, CSRF и SQL-инъекций.

14. Оптимизируйте производительность вашего проекта, используя кэширование, сжатие и минимизацию кода.

15. Регулярно обновляйте и улучшайте ваш проект, следуя принципам SOLID и лучшим практикам разработки.

Видео слишком большого размера, чтобы их можно было эффективно хранить в MySQL. Используйте файловую систему. Придумайте разумный способ сортировки видеофайлов по отдельным каталогам, чтобы в итоге у вас не было тысяч файлов в одном каталоге. Например, все файлы, начинающиеся с 'a', переходят в каталог 'a' и т.д.

Если ваш сайт становится действительно большим, возможно, имеет смысл выгрузить ваши видео на CDN, такой как Amazon Cloudfront.

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

Вместо простого хранения на диске вы можете рассмотреть возможность использования таких сервисов, как Rackspace Cloud Files или Amazon S3, если позволяет ваш бюджет.

Несколько баз данных, которые могут подойти для хранения больших объёмов видео:

— Greenplum. База данных SQL с массовой параллельной обработкой данных, основанная на PostgreSQL. Позволяет масштабировать объёмы данных до петабайт и выполнять параллельные запросы к большому количеству информации.

— Cassandra. Бесплатная СУБД NoSQL с открытым исходным кодом, которая используется для размещения и управления большим объёмом данных, распределённых по многим серверам. Обеспечивает масштабируемость и высокую отказоустойчивость.

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

— Hadoop. Платформа больших данных с открытым исходным кодом, которая позволяет масштабируемо обрабатывать данные. Может работать как локально, так и в облаке.

Выбор базы данных зависит от конкретных требований проекта.

Там хранили в GridFS а не именно в базе, которая в монге позволяет сделать что-то типа распределенного файлового хранилища. Однако я бы не рекомендовал его использовать так как есть более удобные способы организовать хранение файлов на диске. База данных тут не особо влияет.

По поводу что — Разработчик настаивает на PostgreSQL. Я почитал форумы, хвалят MongoDB.

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

Потянет, конечно, вы же сами файлы видео хранить в БД не будете. 

У меня стоит DST Social Network, в моей социальной сети уже более 300К видеороликов и все работает спокойно, даже на MySQL, единственное ничего не переписывали кроме фронта. 

1. Кэширование статики и данных из БД — Вы там не забыли поделить на: EVERYONE, GUEST, USER?

2. Соединение к БД — не переоткрываете по несколько раз, когда делаете обращения к БД за время исполнения скрипта?

3. Объединяете ли запросы с стэки для получения всех нужных данных ОДНИМ запросом из БД?

Клиент — всегда за одну сессию посещения работает ТОЛЬКО с одним сервером обслуживания. Это может быть как отдельная структура, так и внутри структуры CDN. Я предпочитаю использовать второй вариант.

Сервера — постоянно синхронизируют данные асинхронно между собой (канал обмена данными — поднят всегда!).

После закрытия/смены сессии клиентом — происходит централизованное оповещение сразу всем серверам и они ставят себе в очередь синхронизацию данных именно по этому пользователю.

При этом, стандартная синхронизация серверов БД работает параллельно в штатном режиме.

По поводу что все SQL запросы сильно лагают

Только пакетный конвейер запросов с контролем загрузки сервера исполнения запрос-пакета и необходимого приоритета исполнения всех нужных запрос-пакетов! Система должна знать (сама принимать решение!): когда ей выполнить запрос, а когда допускается повременить (приоритезация).

Также, можно использовать HAProxy для отказоустойчивости/балансировки, в качестве «головы».

Или, как альтернативу ему, Envoy.

Например, самое главное (БД) перенесу в Amazon AWS RDS

Основной мощный веб-сервер с SPA и Backend останется в текущем ДЦ в Нидерландах

Хочу сделать резервный веб-сервер в другом ДЦ

Оба веб-сервера будут работать с одной базой в AWS RDS (MultiAZ для надежности)

Виталий Здоровец

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

Варианты от простого к сложному (кроме нанять опытного архитектора):
— выбрать надежного провайдера — самый дешевый и простой вариант
— AWS (или GCP/Azure) — разбросать компоненты по разным AZ
— несколько систем в разных регионах AWS, с GeoIP loadbalancing
— несколько систем у разных провайдеров (разные датацентры), loadbalancing Cloudflare or Incapsula, ...

В случаях 3 и 4 вы сами должны обеспечивать репликацию данных.