Вот вы обмолвились, что для этих целей подошел бы nosql. Но как же проблема с автоинкрементами? Ведь тут все на красивом id завязано. Хотел в последнем проекте использовать монго, но в связи с невозможностью грамотно генерировать иды, необходимые в приложении, пришлось отказаться
Имел дело с монго и кочем
В коче можно сделать через view+reduce. Собственно и сделал, но как только дошло до тестов дело… Оказалось, что он в 10 раз медленнее того же мускула. А в теории все эти статичные запросы выглядели так сладко
В монго такой финт уже не сделаешь
1 — сделал парсер на ноде, все валит в один момент.
2 — тот же монго достаточно скоро потребует шариться, а безопасность атомарных операций там никто не гарантирует
В голове вертятся только гибриды
Автоинкремент в монго можно сделать так: links.freecr.ru/!bvc
Но можно еще подумать над сокращением ObjectId, которое выглядит так:
47cc67093475061e3d95369d
Но как его сокращать, оставляя уникальным — я хз. Мне в проекте это требовалось и я не допёр, но вместо этого я использовал собственную реализацию автоинкремента в монго.
Ну, тут зависит от политики сервиса. Если проверять наличие, то это поиск в хранилище, что увеличивает время создания ссылки и уменьшает размер хранилища. А если не проверять, то ссылка создается быстро, но увеличивается хранилище ссылок.
Популярные укорачиватели такой проверки не делают.
я думал об этом, но. часто бывает, что человек хочет собрать статистику по переходам на урл. например, я в топике выкладываю ссылку и хочу узнать, сколько раз по ней перешли. но, возможно, имеет смысл брать уже готовые, да
Я вот недавно тоже сел за ковыряние ноды, и, не поверите, тоже в голову пришло сделать сокращалку урлов :)
Вот мой вариант: sudn.tk. Исходники покажу по запросу, выкладывать их стыдно.
Там проверки тоже примитивные… yandex.ru и yandex.ru/ посчитает за разные урлы.
Да, делал на ExpressJS, в качестве хранилища редис, шаблонизатор ejs.
Думаю что если сервис будет популярен, то будут частые обращения и любой ФС тут станет нехорошо.
Представьте себе 1к обращений в единицу времени. Это надо прочитать 1000 файлов, получается. Параллельно.
А параллельное чтение большого количества файлов — это либо дорого, либо практически нереально.
Да и наверное память и цпц нынче дешевле дискового пространства.
Я конечно могу ошибаться, ибо не сильно много понимаю в ФС и файловых операциях :)
А кстати да — как можно читать кучу файлов параллельно? Ну то есть тут, как я понимаю всё упирается в скорость чтения головки с хдд и в «раскиданность» файлов по ФС?
При достаточном количестве памяти ОС Linux будет держать кеш файлов в ОП и обращения будут сверх быстрыми. Есть только один подводный камень — fileatime, то есть последнее обращение к файлу. Но при монтировании файловых систем можно поставить noatime и избавиться от этого.
Как дело обстоит в Windows и для NTFS, не знаю.
ещё два подводных камня:
1) ограничение на суммарное количество файлов в файловой системе (вернее, inodes);
2) резкое снижение производительности при большом числе файлов в одном каталоге (но это легко решаемо).
а зачем? по-моему бред и вот почему: сегодня я использую фс, завтра, когда потребности проекта возрастут, буду писать велосипед того, как бы это все красиво заоптимизировать, а послезавтра, когда захочется переехать в облако пойму, что где-то в проектировании системы был прокол. почему бы сразу не использовать бд, которая как раз для этого и создана? не обязательно реляционную, для такого проекта сгодится простенькая key-value бд вроде редис. а чтобы начать работать с ней, нужно меньше времени, чем потом бороться с граблями файловой системы. скажите я не прав?
смысл? если я захочу расширить приложение — я смогу это с легкостью сделать. работа с базой тоже будет безумно быстрой в этом приложении.
тем более, я уже сказал, что можно было бы использовать НоуСКЛ, но целью было именно научится работать с MySQL
Забавно использовать для серверной части MooTools, а для клиентской — jQuery.
Хотя классы там удобные — это факт, а как с этим в jQuery, я не знаю. И как у jq с node.js
я не могу отдать предпочтение определенному фреймворку. наверное, ДОМ мне нравится больше в JQuery. Хотя многие вещи мне больше нравятся в MooTools. Они разные на самом деле
Спасибо за статью, красивый код и доступное описание.
Небольшое дополнения: String.sqlEscape можно было не реализовывать, ведь есть conn.escapeSync(). Потери производительности будут минимальны, но зато точно не забудете заэкранировать что-нибудь, а вы явно забыли \n, \r и т.д. Впрочем, для INSERT уже можно использовать prepared statements.
Да, похоже прежде всего нужно допилить Dox для генерации постраничной документации, а то в едином списке в api.html трудно ориентироваться.
Поддерживать документацию вручную для одного разработчика довольно хлопотное занятие. Но пример с INSERT и экранированием в срочном порядке добавлю в examples.js, моё упущение.
Сервис не развивается, прибыль не приносит и вообще не работает. В общей сложности было сокращенно около 20000 ссылок за первые дни. Нагрузка — близка к нулю, отработал прекрасно.
Не видел смысла, есть куча других проектов. Сокращалок — много, сомневаюсь, что смогу дать что-то особенное.
Хотя, если кто-то станет успешным с кодом, описанным в статье — я буду рад.
node.js сокращатель ссылок