Полная Версия: Как лучше организовать хранилище айпи?
| Цитата (icedfox @ 26.01.2016 - 22:58) |
| в MySQL нет полей для IP, обычно ставят varchar(40) |
Почему 40 ?
_____________
Принимаю заказы, писать в ЛС
| Цитата (icedfox @ 26.01.2016 - 22:58) |
| обычно ставят varchar(40) |
16 ставлю
| Цитата (sergeiss @ 27.01.2016 - 01:07) |
| Это для "пионеров" защита. А на сервере всё равно ж проверять придется, по-любому. |
Я не спорю. Вот только какой процент пионеров из всех посетителей ? Даже если 50% уже оно того стоит.
я храню в VARBINARY(16)
| Цитата (Медведь @ 26.01.2016 - 22:27) | ||
Какой тип лучше для IP в MySQL? |
Зависит от условий.
Если RAM достаточно - ставьте простой varchar.
Ну и по приоритетам конечно:
- varchar - больше RAM, меньше CPU
- binary - меньше RAM, больше CPU
По скоростям будет почти одинаково.
Для ТС (в основном):
Естественно нужно пользовать InnoDB в этой задаче. Про myISAM забыть, напрочь.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
| Цитата (S.Chushkin @ 25.01.2016 - 19:53) | ||
Бред. Даже на слабом серверочке mySQL легко отработает >>100 млн. запросов в сутки, что на порядок больше требуемого для Вашей задачи (5 * 700к записей в сутки). |
вы сначала отработайте потом пишите.
Показывайте как на слабеньком сервочке mysql принимает более 100 млн запросов в сутки.
Причём чтобы они не выстраивали очередь.! Очень жду! Особенно скоко будет Time_wait висеть очень интересно посмотреть=)))
p.s. В моём понимании слабенький сервачёк это 2 ядра по 2200GHz и 4-6гиг озу.
Сервачёк в 2 раза более по ресурсам уже не считаю слабеньким.
Отработать можно и 200 лямов но отработать их почти без очереди когда может быть и 1к запросов в сек а может быть и 5к запросов в сек нереально на слабеньком сервачёчке как вы пишите! Особенно если он удалённый как минимум по мимо всего что описал выше могут кончиться как исходящие так и входящие порты. + mysql расходует больше процессорного времени чем тот же redis. id% cpu ронять не стоит задача. Так же прошу заметить что по мимо mysql на сервере в любом случае крутиться как минимум файрвол который достаточно жёсткий и кое какие ещё системные приблуды.
Ваше утверждение как из 90% статей читаешь статью оу вывез лям соедининей конечно на пустом сервере я вывезу их так же под таким нагрузочным тестированием а ты попроробуй их вывести когда у тебя минимум по 12-13к онлайна сидит постоянно людей из которых 90% постоянно чёто делает ещё возможно и не в 1ой вкладке ситуация будет совсем другая.
И тогда когда твоего проекта онлайн переливает за 6-7 тысяч ты начинаешь понимать сколько подводных камней ты ловишь до этого ты не паришься работает и ладно (из собственного опыта).
т.е. лям уников в сутки может быть легче чем 100к уников в сутки когда у тебя постоянно чёто делает больше 10к чел на сайте так как запросы/раздача и тд могут идти в очень большом количестве.
Кто писал про сессию забудьте сессия зло вообще. Так же не испытвал до 6-7к никаких проблем с ними но когда более 10к если даже писать их в мемкеш то мемкеш ест 8-10% от каждого ядра (8) по 3400ghz. только куки. Сессии никто не использует при большом онлайне. Это мы ещё не скапливали сессии сутки держала максимум. А многие то держут и месяц. при таком даже в хранении в tmpfs сама операционная система захлебнёться. + доступ сессия(мемкеш)->mysql на 20% быстрее чем сессия(tmpfs)->mysql. В мемкеше спасют чанки.
Oyeme
Дал правильное решение. Так и сделаю.
| Цитата (sergeiss @ 26.01.2016 - 18:49) | ||||
Если уж использовать БД, то в Постгре есть тип данных IP. Не надо ничего придумывать, просто берешь и используешь.
Тогда уж лучше в сессию, наверное  |
Всё не доберуться руки до постгре. Как я понял прёт да она? в целом лучше по скорости чем mysql ?
| Цитата (VELIK505 @ 27.01.2016 - 20:13) |
| вы сначала отработайте потом пишите. |
Я прокукарекал, а там хош рассветай хош не рассветай. (с) не мой
Коротко, mySQL легко выполняет >1000 запросов SELECT+INSERT в одном потоке для простых задач, подобных Вашей. Без кеширования.
п.с. А RAM всегда должно быть достаточно для нормальной работы, иначе это не "сервер".
п.п.с. И да, нагрузка CPU будет немного больше, чем в некоторых других решениях задачи.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
| Цитата (VELIK505 @ 27.01.2016 - 20:13) |
| Ваше утверждение как из 90% статей |
Вы описали задачу и получили ответ для рабочего решения.
А уж правильно/точно Вы описали задачу или нет, это не проблема отвечающего.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
S.Chushkin
так я писал сразу же что Как бы вы организовали чтобы задействовать минимум %CPU?
поэтому впринципе моё решение таблицы memory и базука в tmpfs имеет место очень даже быть так как даже mysql->ssd отстаёт от mysql->tmpfs и при запросе не из query_cache что в большенстве раз и будет в таком случае мы будем тратить больще процессорного времени имея
имея в добавок более долгий.
А и да прошу прощения показалось что ты отписал что mysql в tmpfs бред.
Ну а так как пример щас точно не вспомню но у нас на 3х ядрах при 3к запросов в сек захлёбывался сам mysql-server из за того что невозможно было увеличить число одновременно работающих потоков mysql-server(а) thread_concurrency/innodb_thread_concurrency хотя запас ресурсов был в этот момент более 50%
так я писал сразу же что Как бы вы организовали чтобы задействовать минимум %CPU?
поэтому впринципе моё решение таблицы memory и базука в tmpfs имеет место очень даже быть так как даже mysql->ssd отстаёт от mysql->tmpfs и при запросе не из query_cache что в большенстве раз и будет в таком случае мы будем тратить больще процессорного времени имея
имея в добавок более долгий.
А и да прошу прощения показалось что ты отписал что mysql в tmpfs бред.
Ну а так как пример щас точно не вспомню но у нас на 3х ядрах при 3к запросов в сек захлёбывался сам mysql-server из за того что невозможно было увеличить число одновременно работающих потоков mysql-server(а) thread_concurrency/innodb_thread_concurrency хотя запас ресурсов был в этот момент более 50%
| Цитата (VELIK505 @ 27.01.2016 - 21:27) |
| так я писал сразу же что Как бы вы организовали чтобы задействовать минимум %CPU? |
А, точно. Извиняюсь, как-то пропустил.
И всё же, для Вашей задачи (фактически это плоская таблица, насколько я понял) на 3М записей и для пиковых ~1000 запросов/с я бы использовал InnoDB. Это просто, без наваротов и нагрузка будет в пределах 100% одного ядра. Конечно, при условии, что mySQL сервер отдельный (хотя и совмещённый с http-сервером тоже легко потянет, на среднем сервере). И только когда это станет действительно узким местом, стал бы прикручивать внешний кеш или тот же Redis.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
| Цитата (VELIK505 @ 27.01.2016 - 21:00) |
| Всё не доберуться руки до постгре. Как я понял прёт да она? в целом лучше по скорости чем mysql ? |
По скорости вряд ли, плюс-минус примерно то же самое - для базовых вещей. Если в мускуле взять MyIsam, то будет даже быстрее будет
Но зато не надёжно.Постгре хорош тем, что там существенно больше возможностей по сравнению с базовым SQL. Какие-то позволяют настроить систему на более быструю работу, другие - упрощают запросы. Третьи позволяют организовать БД так, чтобы вне БД был минимум обработки. Впрочем, на эту тему я уже много писал на форуме, не буду повторяться. А также есть и новые типы данных, например те же IP или JSON, которые переводят работу с БД на несколько иной, более высокий уровень.
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
sergeiss
Спасибо буду смотреть на днях. просто да как ты и повторился что есть и новые типы данных, например те же IP или JSON. и прочие плюшки о которых я читал не хватает в mysql, хотя я не пойму почему это проблема для разработчиков mysql усовершинствовать скоко не обновлялся с 5.1 до 5.5 до 5.6 до 5.7 ничего нового не добавили токо так усовершенствуют скорость и прочее а так чтобы теже поля типы данных добавить нефига, что очень странно по сути
Спасибо буду смотреть на днях. просто да как ты и повторился что есть и новые типы данных, например те же IP или JSON. и прочие плюшки о которых я читал не хватает в mysql, хотя я не пойму почему это проблема для разработчиков mysql усовершинствовать скоко не обновлялся с 5.1 до 5.5 до 5.6 до 5.7 ничего нового не добавили токо так усовершенствуют скорость и прочее а так чтобы теже поля типы данных добавить нефига, что очень странно по сути
| Цитата (VELIK505 @ 27.01.2016 - 22:36) |
| ...чтобы теже поля типы данных добавить нефига |
JSON уже несколько месяцев есть.
IP - не помню, добавили или нет.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
Здесь расположена полная версия этой страницы.