реализация хранения ссылок в tinyurl сервисе

Question

[nikitasius]

Есть идея сделать ресурс (сколько их уже?) коротких ссылок, вроже tinyurl или bitly, tiny-адресс есть («звучный» домен вида ***.**), но вот с технической частью вопросы…
По порядку: использоваться он будет юзерами на форуме, мною лично, ну и тем, кому просто приглянется.
-сбор статистики будет реазизован через Google AppsEngine (сервлетом счетчиком посещений + какие ссылки популярны + будет генерироваться часть статистического контента)
-фронтом на сервере будет вкыступать nginx, который помимо общения с беком (если back будет) будет дергать данные из сервлета на ГуглАппс и вписывать его в страничку.
А вот далее начитаются вопросы…
В интернете и на Хабре есть заметка, как пользователи реализовывали подобные вещи через готовые решения или самописные, кои можно найти через поиск.
Но все они (все что я видел, а видел я мало) работают с базой. Варианты БД два:
1) не транзакционная
2) транзакционная

В первом (mysql-myisam) случае малый (до поры) расход оперативной памяти, но при выборке или инсерте таблица блочится на запись и чтение соотвественно. Во втором (mysql-innodb, оракл не ставим) случае блокировки на уровне записей, но нагрузка из-за транзакций и ситуация когда таблички и база будут разрастаться, ибо наша идея хранить все ссылки. На первый порах проект будет для «себя и друзей» и нагрузка будет если что от ботов или хацкеров.
Но хочется сделать проект, ориентированный на большую нагрузку, дабы выжать все. Например 50-100 запросов url в секунду это 4-8 миллионов в день (картинка, запостенная в одном топике на хабре, который попал в топ24, дергалась 0.5-2 раза в секунду, к примеру).
Я расчитываю на более скромные цифры (10-20 запросов в секунду), но на сервере уже есть проекты, которые кушают его ресурсы.

У меня возникла идея — что если хранить данные о ссылках в виде локальных файлов и подпапок. ext4 дает до 64к папок в подкапке. То есть вполне реально разложить /a/aa, /a/ab… где будет лежать рой файлов вида abcd.ext (ext расширения, для удобства), которые будут давать ссылку вида ***.**/aaaabcd (естественно nginx будет ее обрабатывать через regexp).

Ссылки(файлы) будут генерироваться perl на стороне nginx (front без back, perl модуль в ./configure) или back'ом в виде fastcgi-php или tomcat/jboss+jsp, и затем писаться в файл.

Не станет ли линуксу (или дисковой подсистеме) плохо от частых запросов на хард? Страничка на харде будет содержать только линк и будет доформляться nginx в соотв. с конфигом и данные от сервлета с ГуглАппс.

Если есть готовые решения, исключающие использование БД, или статьи, описывающие, что использование дисковой подсистемы не разумно — пожалуйста ткните меня носом линком в них.

Немного о сервере — «магазинный» сервер от Hetzner, AMD 2 ядра, 2Gb RAM & 400Gb raid-1 (soft), в будущем вероятен переход на EQ4 тариф, если текущего будет мало (хотя его хватает на все, что там висит).

Answer 1

[Виталий Перетятько]

А что если хранить все в redis? Вроде для nginx даже модуль есть, который позволяет ему брать данные непосредственно из Redis.

Comments

[nikitasius]

спасибо за наводку на redis. обязательно почитаю!

[pietrovich]

nosql.mypopescu.com/post/1010844204/redis-memory-usage

[nikitasius]

решено за Редисом. Хард много iops'ов не вытянет (если не отдать весь сервер под это дело), а так хард+оперативка.
Всем спасибо за полезные советы!

Answer 2

[fossdev]

Рискую отхватить 100500 минусов от php'шников, но 100 запросов в секунду — это серьезная нагрузка лишь для связки Apache/php/SQL. Функционал несложный, делайте fastcgi на си, для хранения ссылок используйте key-value хранилище вроде memcache, и 2-3 тысячи запросов в секунду на средненьком сервере не будут казаться чем-то запредельным. Если сделать все правильно, то производительность будет ограничиваться шириной канала.

Comments

[nikitasius]

у меня стоит php-fpm. memcached использует ОЗУ. Почитал про redis, он вроде бы еще и на hdd данные может хранить. Так что выбор пал на redis для всей базы, или же redis для топ популярных ссылок и mysql для храния всех ссылок вообще, но в этом варианте прийдется хорошо подумать.
Вариант с хранением файлов практически отмел, так как тестил сервер через fio, выдается 175 iops. С другой стороны можно вместо варианта mysql+redis сделать files+redis, чтобы популярные данные дергались с redis'a, а прочие — из папок с файлами. Сейчас почитаю про tr.im, может что надумаю тоже. Спасибо.

Answer 3

[XPilot]

Возможно оффтоп, но может быть вам будет интересно посмотреть как сам сервис был организован в почившем tr.im (автор [eze] почему-то спилил исходники, но народ успел нафоркать)

Comments

[nikitasius]

большое спасибо, посмотрю. Увы, плюс не могу поставить, хомячки из топика про 'вконтакте' попортили карму:)

Answer 4

[pietrovich]

То что Вы пытаетесь придумать на базе FS это эдакий «шардинг» файликов в папочке. Что мешает шардить данные в БД?
Да и от 20-30 запросов FS не приляжет.

я бы на вашем месте поступил проще — реализовал бы тот вариант хранения который для вас проще в реализации именно сейчас, при этом укрыв его реализацию за каким нибудь IStorageEngine. А в дальнейшем, если окажется что он подбирается к порогу производительности мигрировал на другой, который тоже реализовывал бы IStorageEngine. Благо к тому времени и статистика подберется, и требования будут понятны и, наверняка, будет время для тестирования и выбора подходящего варианта хранения. А перелить данные всегда возможность найдется, особенно если продумать систему которая бы выдавала «ключики» в заданных множествах, не пересекающихся между версиями.

Comments

[nikitasius]

стоит задача изначально выбрать оптимальный вариант, под максимальную нагрузку. Проще реализовать вариант с БД+jsp/php, так как там шаманства меньше с конфигами nginx и добиванием знаний perl'а.

Answer 5

[dom1n1k]

В порядке полуоффтопа.

Года полтора назад я всерьез размышлял над созданием аналогичного сервиса. Размышлял долго, но в конечном итоге передумал. При внешней простоте самой идеи, практическая реализация натыкается на множество подводных камней.
1. Сегмент очень конкурентен, сервисов множество. Плюс все крупнейшие «генераторы спроса» на короткие ссылки (твиттер, гугл-мапс и т.п.) уже обзавелись «придворными» сокращателями. Чтобы завоевать аудиторию, нужно предложить какую-то свою интересную специфическую фишку (например, я думал сделать супер-подробную статистику).
2. Ограниченные возможности монетизации при больших затратах на хостинг. Сервер нужен мощный, способный обрабатывать уйму запросов в день (не забываем про статистику), но крутить там рекламу по понятным причинам бесполезно. Я предполагал сделать сервис полностью платным (порядка 5 баксов в месяц), ориентировав его на «профессиональную» аудиторию — именно им нужна статистика, отчеты и пр. Это в свою очередь поднимало вопрос саппорта пользователей.
3. Весьма нетривиальное технологическое устройство внешне простого сервиса — это видно и по вашему топику.
4. Большая проблема спама.

В итоге у меня получилось, что нужны очень большие (во всяком случае для одного человека) трудовые/временные/денежные затраты при крайне неочевидных перспективах. А вдруг не выстрелит? И даже более вероятно, что не выстрелит :) В итоге этот проект был вытеснен из головы другими идеями.
Я не отговариваю — видно, что вы продумываете всё достаточно серьезно — просто мысли вслух.

Comments

[nikitasius]

Спасибо за столь ценную информацию и я с вами согласен, особенно после слатистики на Битли мне даже поплохело:)
буду думать…

Answer 6

[ertaquo]

Как насчет варианта хранить все в базе (sql или nosql), а часто запрашиваемые ссылки кешировать в память (MEMORY-таблица с MySQL, memcached или хотя бы shared memory)? Статистику для кешированных адресов можно будет отслеживать при помощи дополнительной переменной в том же кэше, делая ей инкремент и периодически сбрасывая ее значение в основную базу.

Answer 7

[ComodoHacker]

использоваться он будет юзерами на форуме, мною лично, ну и тем, кому просто приглянется.

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

Это архитектурная ошибка. Если хотите, чтобы заработало, сделайте как можно проще.

Answer 8

[Степан]

Как Ваши успехи? Сделали?
Спрашиваю, потому что хочу в качестве эксперимента сделать аналогичный сервис.

Comments

[nikitasius]

Я в итоге забил на этот сервис в виду нехватки времени и других задач.

Но если бы делал сейчас, то держал бы ссылки в mariadb, статистику по кликам в redis (которую бы периодически скидывал в основную базу), и все было бы за кешем cloudflarе. В случае с CF не нужен толстый сервер, прокатит и простая ВПСка (при правильном кеше).

Да и cloudflare большей части чтобы ip спрятат и защитить от ддоса. Без него кеш nginx вытянет проект в легкую.