Например? Применительно к задаче? При хранении большого обьема данных, при необходимости быстрого доступа, например по индексу, чем?
Я наверное не понял, Имеешь ввиду что SQLlite не реляционная?
Когда? Как-то все ответы не подтверждены.
Например, если ТС будет хранить данные в NoSQL DB like MongoDB, он получит самый быстрый доступ по хэшу обьекта, остальные способы не сравнятся. Но проиграют по памяти
Про преимущества файлов.
В стартпосте речь идёт о YouTube. Мне приходилось писать утилиту для работы с его API. Для работы с ним характерны большие объемы данных и низкая финансовая прибыльность. Заказчики подобных проектов зачастую не готовы и не умеют работать с БД, которые уже на старте проекта достигают размеров в районе 200-300 Гб. Не могут ни сделать бэкап ни развернуть его.С текстовым файловым хранилищем, особенно партиционированным, всё намного проще. Повредить его сложно. Восстановить легко. Протестировать или модифицировать легко. Получается аналог portable софта, работать с которым может человек без подготовки.
В моём тезисе про SQLite и альтернативы не было противопоставления. Придирка ни о чём.
Mongo многим приходит в голову, когда нужно быстро искать по чему-то вроде ID и хранить привязанную к каждой такой записи неопределенную кучу разнородных данных. Для YT это может быть актуально. А может и не быть. Зависит от потребностей и планов бизнеса.
Конкретно для случая ОПа, до сотни миллионов записей я для начала попробовал бы сделать именно партиционированные текстовые файлы. Например, по двум первым "буквам" ID, если он гарантированно ASCII буквенно-цифровой. Искал бы построчным чтением с брейком в случае нахождения строки. С хорошим объемом RAM файлы будут в кеше ОС и всё должно быть быстро. А писал бы обычным для Unix 'my str' >> /target/file.txt.
Но всё нужно тестировать. И для конкретно этой задачи тестирование альтернатив не выглядит проблемой. Для проверки эффективности каждого подхода должно хватить не более сотни строк кода.
Про подтверждение ответов.
Это вообще к чему? Я тут не кандидатскую защищаю, а развлекаюсь на форуме. Как захотел, так и написал. Не нравится - напиши лучше 👍
Зависит от того, как именно вы проверяете наличие нужной записи в файле.
Зачастую файл заметно лучше БД. Иногда лучше SQLite, иногда - реляционная СУБД, а иногда и не реляционная.
Один из худших, но распространенных в мире PHP способов - зачитать файл в память, заполнить строками условный массив и искать по этому массиву.
Ну вот напишу плохо про яндекс.
В последнее время у яндекса плохо работают не только программисты и менеджмент, но даже дизайнеры.
Их новая инициатива про наряжание ёлки выглядит так себе. Что со вкусом у человека, утвердившего рисунки игрушек?
Да и в целом, все отличные элементы интерфейсов, что мне известны у яндекса, сделаны вероятно 10, а то и все 20 лет назад.
Во-первых, есть смысл заглянуть на тот bad(.)site
Во-вторых, нужно посмотреть в логах какой объем посетителей потенциально теряется. Сколько всего таких запросов.
В третьих, тому сайту не обязательно блокировать доступ. Можно отдавать улучшенные версии запрашиваемых файлов. Кто-то даже попробовал бы JS-редирект на свой сайт, но это не могу рекомендовать, в некоторых юрисдикциях может оказаться незаконно.
Добрый день!
Не нашел в списке доступных способов вывода Tinkoff QR и Tinkoff Cash-in.
Еще в Правилах есть такие пунткы.
6.1. Сервис не выступает в роли налогового агента для Пользователя и не осуществляет информирование Пользователя о его налоговых обязательствах. Пользователь обязуется самостоятельно уплачивать все налоги, соответствующие требованиям налогового законодательства своей юрисдикции.
Зачем обязывать Пользователя перед третьей стороной? Ладно бы если "Пользователю предлагается", но тут описывается возникновение обязательства.
И вот это. Получается, за использование VPN деньги могут быть приняты и конфискованы?
3.10. Пользователь обязуется не применять способы сокрытия своего физического местоположения при доступе к сайту и соглашается сообщать Сервису о своем точном и истинном местоположении по запросу. Если Сервис, на основании анализа пользовательских транзакций или с использованием специализированных технических инструментов, определяет, что деятельность на аккаунте Пользователя подозрительна или связана с незаконной деятельностью, Сервис вправе приостановить функционирование аккаунта Пользователя, заблокировать невыполненные транзакции и отклонить последующие операции.
их нет смысла кешировать.
Я за кеширование:- требующих вычислений, но не требующих частых обновлений блоков HTML- результатов тяжелых запросов к БД или обращений к API- результатов медленных разборов, валидации и коррекции каких-нибудь XML или JSON
В случае редко меняющегося текстового контента на одном языке вообще сложно представить что может пойти не так. Может быть дело в особенностях/баге конкретного экземпляра приложения. Либо 1 GiB слишком мало.
Перед использованием кеши желательно прогревать простым скриптом, чтобы не создавать записи по одной во время работы. Загрузив первую тысячу записей и посмотрев статистику можно оценить сколько RAM потребуется для полного кеша, а затем прогреть до 90% доступной памяти выборкой самых нужных статей. Например, сотней тысяч самых новых.
Иногда редис тоже ложит сервис будь здоров
Возможно и такое.
Однако единственный пример такого случая встречал, когда делают flushall без async-а.
А так, если параметры maxmemory* и maxclients заданы корректно, что с ним может случиться?
Конечно, если кто-то еще использует Redis как БД и пишет на диск, нюансы возможны. Давно не видел таких людей. Обычно Redis только для работы с RAM.
Я бы рекомендовал неспеша переходить на redis.
Настроить его легко, положить - сложно. И статистику смотреть удобно.
А вы блокируете ботов уже непосредственно на сайте, т.е уже после посещения? До загрузки метрики вычислить бота наверное невозможно?
Может быть вам ваши наработки в софт монетизировать?
Метрика, GA и подобные JS-инструменты - это в основном для маркетологов.
Больше того, если на бэкенде мы видим, что пришел бот, то скрипты аналитики ему (часто) не отдаются, чтобы не засорять отчеты для маркетинга.
Бот обычно вычисляется за несколько запросов к точке входа приложения. С блокировкой - сложный вопрос. Есть процент настоящих клиентов, которые зачем-то покупают VPN-ки в чернейших подсетях. У таких изначально хуже ботовый рейтинг, но обычно даже их принято пропускать.
Ну так они и не совсем мои. И мало кому интересны.
А grep-ами поиграть бывает интересно, да. Для себя. Там теории на час изучения и можно узнать из своих логов что-то полезное.
