Реализация превью статьи?

Question

[x2bool]

Здравствуйте. Потребовалось реализовать превью (частичный показ статьи). Можно сравнить с Хабром: на главной несколько урезанная статья; при переходе по ссылке — полная версия! Как спроектировать реализацию на SQL?


На данный момент есть три идеи:

1. Хранить статью в одной ячейке вместе с меткой (habracut). При надобности разбивать на две части
   
2. Хранить статью в двух ячейках. При надобности соединить в одну
   
3. Хранить статью в одной ячейке. Распарсить при первом сохранении. В отдельной ячейке хранить позицию метки. При надобности разбить на две по сохраненной позиции метки
   

Сам я склоняюсь к варианту №3. Интуитивно кажется, что вариант должен быть самым производительным. Как думаете вы? Может есть еще варианты?

Answer 1

[Progrik]

Если не критичен размер БД, то 2, но без соединения (т.е. в первой ячейке анонс, во второй целиком статья).
Если не критично время, которое требуется чтоб каждый раз дёрнуть нужные статьи из БД и порезать их пополам, то 3.

Лично я использую 2й вариант и не чувствую угрызений совести.

Comments

[65520]

Авторы разных CMS тоже не чувствуют угрызений. Я бы тоже поступил так же.

Answer 2

[ikra]

Что за вздор?! Конечно же достаточно двух полей: article_аnounce и article_text.

Answer 3

[Виталий Желтяков]

Вижу меня не до конца понимают, поэтому опишу подробнее.

— Нужна таблица с полями: id и anounce.
— На главную страницу выводим блоки текста с этой информации. По клику открываем статью с нужным id.
— Статью целиком берём из файла с именем .php

Преимущества:
— Не загружаем тяжёлыми запросами СУБД. Запросов меньше.
— Опкэшер сам кэширует статьи. Без каких либо танцев с бубном.

Comments

[Виталий Желтяков]

Чёртов парсер… Должно быть:
«Статью целиком берём из файла с именем id_статьи.php»

[ikra]

В чем тяжесть запросов? Это же элементарные операции.

Answer 4

[Виталий Желтяков]

Самым производительным вариантом будет хранение статьи в файле, а в БД хранить только ссылку на файл.

Comments

[jj_killer]

Ого, сурово. А как же поиск, бекап, кеширование?

[Виталий Желтяков]

По поводу кэширования:
— Строки с текстовыми полями в MySQL не кэшируются.
— Файлы автоматически кэшируются ОС.
— Файлы можно кэшировать при помощи опкэшера.

По поводу бекапа:
— Файлы тоже можно бекапить.

По поводу поиска:
— Сфинкс прекрасно ищет по файлам.

[jj_killer]

– я не о том кэшировании
– ОС кеширует много чего еще
– можно, еще на tmpfs сохранять, но зачем?

– не просто можно, нужно, но опять же, не ясно преимущество

– еще и сфинкс ставить?

[Виталий Желтяков]

— А о каком кэшировании? Через memcached будет медленнее.
— Это происходит автоматически и никогда дополнительное кэширование не помешает.
— Как зачем? Что бы весь проект с текущими статьями висел в памяти и брался от туда.

— А это не преимущество.

— То есть как ещё? Вы что поиск по текстовым данным организуете без Сфинкса?

[jj_killer]

– кешируется ответ на sql запрос, не важно есть ли там TEXT или BLOB
– еще как может помешать, более того, если это не только сервер БД, а еще файловое хранилище, то эти txt-шки могут не попадать в кэш вообще
– это если очень скромный проект и очень много ОЗУ

– вот сейчас буду докапываться :) во первых, потери свободного места, мелкие файлы занимают целый кластер, во вторых огромное количество файловых дискрипторов, что плохо как для работы ОС, так, например, и для перемещения/копирования/разворачивания из бэкапа, представьте, что там миллион файлов; оно копироваться вечно будет.

– конечно же без Сфинкса, вот на хабре Сфинкс, фиг что найдешь. Вообще редко нужен серьезный полнотекстный поиск, но когда нужен есть Solr.

[Виталий Желтяков]

— Да, их можно кэшировать, но какой ценой — кэш переполняется «тяжёлыми» ответами, кэширование для других запросов становиться неэффективным и общая скорость СУБД падает.
— Что за бред? Вы что, умеете отключать автоматическое кэширование файлов в ОС?
— То же самое можно сказать про кэширование средствами MySQL. Или каким-то чудесным способом кэшируемая информация меняет свой объём попадая в кэш MySQL?

— Миллионы? Ну-ну, у Вас богатая фантазия. Возьмём тот же Хабр — всего 140000 статей.
Потом, что мешает Вам разделить файлы по папкам.
И подозреваю, что Вы никогда не заливали на сервер dump в полгига — вот это вечность.

— Хотелось бы взглянуть на ваш чудо-поиск без Сфинкса.

[jj_killer]

– тяжелыми, это какими 200Кб?
– нет, не умею, и не понимаю причем это здесь
– нет, не меняет, но MySQL знает с чем работает и знает когда ему это нужно, сказал MySQL, что заберет 3Гб для кэша запросов, сделал, файловому кэшу без разницы, что одни данные важнее, а другие нет, если он «переполняется», от начинает использовать всю незанятую ОЗУ, а если она становится нужна для чего-то, освобождает ее. С последствиями.

– миллионы, да-да. Это не обязательно могут быть статьи, может быть обычная документация, знали бы вы сколько проходит ее в серьезных финансовых конторах за день, удивились бы. Разделять можно, только толку от этого никакого, современные ФС не имеют ограничений на количество файлов в папке. Насчет полгига и сервер не понял.

– Интернет есть, там полно примеров, ищите.

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

Answer 5

[jj_killer]

Да и по первому пункту попробуйте так:
SUBSTRING(`text`, 1, (INSTR(`text`, "[habracut]")-1))

Comments

[x2bool]

Мне кажется это самый дорогостоящий вариант.

• В случае надобности полной версии придется убирать метку из текста
• Если нужна только часть, придется производить данную операцию при каждом обращении к бд

[jj_killer]

– Метку можно убрать средствами языка, практически во всех них функции замены в тексте работают достаточно быстро
– Мне трудно сказать насколько это медленно, можете провести синтетический тест. И еще мне кажется результат такого запроса должен попадать в кэш.

Answer 6

[Evengard]

Два поля. В одном — только то, что до метки ката. Вторая — вся статья (как и то, что до метки ката, так и после)

Конечно, получается дублирование данных. Но если вам CPU важнее, чем место на харде, то почему нет?

Comments

[ikra]

А зачем анонс и в поле полного текста сохранять? Ведь достаточно при сохранение текст разнести. При отображении полной статьи и в форме при редактировании склеить.