Так а в чём проблема спросите вы? Есть mbstring, используй и радуйся.
А дело в том, что разработчики решили поддержать юникод не на уровне библиотеки, а на уровне ядра. Это означает, что любая php-функция, а также строковые операторы, в потенциале, могут принимать в себя юникод и более менее гарантировать, что юникод символы не будут исковерканы, удалены и не произойдёт ошибки. Кроме того, сам mbstring реализует далеко не все стандартные строковые функции.
Тоже не понял, о чём статья. Описываются данные, но даже не указан их объём в байтах (или я не нашёл), не указаны настройки mysql, может быть, там индексы в память не влазят (не говоря уже о данных). Если структура простая (id -> word), то можно и в мем-кешеде хранить, почему бы и нет.
Если честно, не понял ваш алгоритм, вернее, разбираться лень.
У меня такая мысль возникла. Можно что-то типа бинарного поиска сделать, если индекс на колонку есть. Например, зная минимиальный и максимальный id, делаем выборку count(*) where id < (min_id + max_id)/2 и, сравнивая count(*) и ожидаемое кол-во понимаем, есть ли в «младшей» половине ID'ов дырки. Далее делим нужную половину опять попалам и т.д.
Для миллиона записей в худшем случае нужно сделать 20 выборок (log_(2)_1000000)
А в вашем алго сколько выборок сделается в худшем случае?
Насколько я понял из курса по mongodb. Каждая коллекция представлена в виде отдельного файла, вернее файлов т.к. файл коллекции разбит на куски фиксированного размера (грубо говоря). Новые куски(новый файл) создаются по мере роста коллекции. В каждом куске лежит BSON, это почти JSON, тока оформленный так, чтобы можно было быстро обращаться к нужному куску JSON-документа, сконвертированного в BSON-форму. Также в этих файлах хранятся и индексы как-то.
Ну вот, видимо, ребята из MongoDB научились делать блокировку отдельных регионов этих файлов и не ставить lock сразу на все файлы коллекции, как раньше.
Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
Other issues to consider is that most indexers will not index special characters such as !@#$%^&*()_+[]>< These are desirable searches when looking for source code. Once you realise someone might want to search for List
Там блог проекта есть (или это блог автора проекта)
Кажется, там описаны, техническию нюансы реализации. Хочу почитать, может и другим интересно будет.
Вот ссылочка www.boyter.org/
Нужна кнопка с картинкой минуса. Чтобы можно было на неё нажать. Один раз. Один клик. Через AJAX. Нужно чтобы сайт считал кол-во минусов и отправлял в сортир заминусованные вопросы. Всё.
> 2. Сами пользователи должны научиться отличать комментарий от ответа и понимать, что значит лайкнуть простой комментарий (типа «я тоже так думаю») это совсем то же самое, что лайкнуть ответ, признав такиим образом его полезность для себя и окружающих.
А мне кажется лайк именно полезность и признаёт. Просто полезность штука относительная. Школоло и профи с 10-летним стажем будут задавать разные вопросы, отвечать разные ответы и зачастую не понимать друг-друга. Профи не понимают, как можно такую тупость спрашивать. Школоло не понимают, что им такое абстрактное говорят и смеются, почему, мол, нельзя просто написать по шагам, что им делать ближайшие десять лет и какой модный язык выучить, чтобы достичь нирваны.
Какой процент от 1.3 ярда составляют живые пользователи т.е. не боты?
Почитайте ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%BE%D0%BA%D1%81_%D0%B4%D0%BD%D0%B5%D0%B9_%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F
А тут сюжет какой-то затянутый и местами непонятный. Я вот, честно, не понял, почему робот сначала махал кулаками, а потом сдулся.
Музыка. Слушаю, кажется, вот-вот начнётся развите темы, ан нет — опять на очередной круг какие-то завывания удут.
Я считаю, от качества спец-эффектов толку мало, если нет продуманного сюжета и качественной музыки.
У меня такая мысль возникла. Можно что-то типа бинарного поиска сделать, если индекс на колонку есть. Например, зная минимиальный и максимальный id, делаем выборку count(*) where id < (min_id + max_id)/2 и, сравнивая count(*) и ожидаемое кол-во понимаем, есть ли в «младшей» половине ID'ов дырки. Далее делим нужную половину опять попалам и т.д.
Для миллиона записей в худшем случае нужно сделать 20 выборок (log_(2)_1000000)
А в вашем алго сколько выборок сделается в худшем случае?
Насколько я понял из курса по mongodb. Каждая коллекция представлена в виде отдельного файла, вернее файлов т.к. файл коллекции разбит на куски фиксированного размера (грубо говоря). Новые куски(новый файл) создаются по мере роста коллекции. В каждом куске лежит BSON, это почти JSON, тока оформленный так, чтобы можно было быстро обращаться к нужному куску JSON-документа, сконвертированного в BSON-форму. Также в этих файлах хранятся и индексы как-то.
Ну вот, видимо, ребята из MongoDB научились делать блокировку отдельных регионов этих файлов и не ставить lock сразу на все файлы коллекции, как раньше.
Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
* www.boyter.org/2014/06/sphinx-searchcode/
* www.boyter.org/2014/06/searchcode/
Кажется, там описаны, техническию нюансы реализации. Хочу почитать, может и другим интересно будет.
Вот ссылочка www.boyter.org/
После написания парочки просьб возникает понимание того, что проще, наверное, сразу писать, куда нужно пойти вопрошающему с такими вопросами :))
* гик
* «гик»
* глупый вопрос
* «глупый» вопрос
Все эти термины присутствуют, например, в вашем предыдущем сообщении.
А мне кажется лайк именно полезность и признаёт. Просто полезность штука относительная. Школоло и профи с 10-летним стажем будут задавать разные вопросы, отвечать разные ответы и зачастую не понимать друг-друга. Профи не понимают, как можно такую тупость спрашивать. Школоло не понимают, что им такое абстрактное говорят и смеются, почему, мол, нельзя просто написать по шагам, что им делать ближайшие десять лет и какой модный язык выучить, чтобы достичь нирваны.