Как стать автором
Обновить

Не вырубишь топором… — ВКонтакте хранит удаленные публикации

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров15K
Всего голосов 26: ↑25 и ↓1+33
Комментарии51

Комментарии 51

Пометить удаленным быстрее, меньше нагружает СУБД, не вызывает фрагментацию.

Полное удаление - весьма тяжелая операция.

Классика sql.

А если вместо удаления перезаписывать данные рандомным набором символов? На фрагментацию же не должно повлиять. Да и оригинальной информации не останется, что равно удалению.

Отвечу честно: это никому, кроме пользователя, не выгодно, и денег с этого не срубишь, а затраты по сравнению с просто атрибутом hidden - ощутимы.

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

Пользователь этого не может проверить, поэтому ценность минимальна

Выплата зарплаты, знаете ли, тоже очень убыточна. А уж как базу данных напрягает!

Вы правы. Как думаете, с чем связаны "массовые увольнения в большом айти", которые точно где-то были? Если бы просили достаточно мало (а ещё лучше - приплачивали бы сами) и работали бы намного больше - то явно обошлось бы без увольнений.

Достаточно просто отредактировать текст поста (заменив его на нейтральный текст) и сохранить, а затем уже удалить пост. В большинстве случаев сохраняется только последняя версия поста, поэтому в системе он после удаления останется с этим вашим нейтральным текстом. А через некоторое время он и в бэкапах перезапишется.

в большинстве СУБД (Oracle и PostgreSQL точно) update добавляет новую версию строки, а старая помечается к удалению. Связанно с требованием поддерживать транзакционность.

Но проблема явно не в заботе о перформансе, а о товарище майоре

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

Зависит от СУБД. В постгресе никакой разницы нет. Любое изменение создаст новый tuple, а старый попадёт под пылесос (а может и нет)

Полное удаление - весьма тяжелая операция.

Но с другой стороны, разве удаление ненужного не будет уменьшать объем хранимой в базе информации и упрощать работу с базой, в том числе бэкапы?
Удаляем то один раз, а если храним, то годами.
Другой вопрос, что удалять лучше не сразу, а периодически, в периоды когда сервера меньше всего загружены другой работой.

Цена хранения 1 гигабайта - 0.02 доллара.

Объёмы информации (особенно текстовой) значения нынче не имеют.

В год? В день? В секунду?

Да.

Там не SQL, а олимпиадный text-engine.

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

Это когда-то (годы назад) поправили.

Если не ошибаюсь, фикс был такой: в моменте меняем URL-адрес на другой, а раз в n недель всё накопленное удаляется по расписанию)

Вообще предполагаю что оно находится потому что есть обратный индекс: для ключевого слова хранится массив id документов, которые ему соответствуют, и этот индекс раз в полгода год подчищается. Сами слова уже по алфавиту или хешмапе, чтобы быстрее искать. Далее массив айди для каждого слова пересекается (через "И") и список айди который есть в обоих ключевых словах - и есть результаты. Такое будет работать и после удаления оригинального документа, и после пометки его удаленным. А вот без подобных индексов (чисто по текстам) сделать поиск подобный вконтакте - никак нельзя.

На месте vk я бы наверное просто скрывал вместо пометки "скрыт"

индекс раз в полгода год подчищается

Записи, которую искал автор поста, 12 лет. Или я не совсем понял вашу мысль?

Это не важно, важно как давно она была удалена.

Аналогично если переслать куда-нибудь (хоть самому себе) чужое сообщение из диалогов. Сколько бы отправитель не удалял в диалоге, само сообщение можно почитать (послушать) после этого. Пару лет назад точно так было.

Ну вот это как раз логично и правильно, мне кажется. Страховка от "Ничего я подобного не отправлял".

Так и использую. Скриншот это картинка, нарисовать могу всякое. А тут вот, пожалуйста, с любого устройства с сервера отдаётся одно и то же. Согласен, в этом случае информацию необходимо сохранить. Вопрос в том, сохраняются ли остальные "удаляемые" сообщения зачем-нибудь или почему-нибудь.

Точно так же телега ничего не удаляет. Иногда всплывают давно удалённые чаты. Никакой заботы о том, что это дорого хранить. Но вот продолбать Saved Messages без возможности восстановления - легко. Но фото обязательно шакалить в 1280px по широкой стороне с 87% сжатием.

Ну и вообще привыкайте, что всё что вы не сами хостите - собирает все ваши данные, учится на ваших голосовых записях, фото и видео и т.д.. Если вы любите слать голосовые, селфи и продалбывать по три аккаунта в год - вы вообще первые в очереди на мошенников, которые будут вашим голосом названивать по вашему контактлисту (сохранённому там же) и в банк даже если абсолютно лояльны и не интересны с точки зрения держателей этой фермы по собиранию компромата.

А он шакалит даже когда как документ заливаешь?

Вообще не должно. Но недавно вот мне показалось что тоже шакалит, но не так сильно. Правда, есть вероятность, что это была функция самого телефона у человека, который отправлял фотку в телегу. Это надо проверить - скинуть фотку как документ, на другой стороне сохранить, и сверить какую-нибудь md5 и там и там.

Фото как файлы не шакалит, "какфайлы" побайтово совпадают, но... надо понимать что тогда это всё не выглядит как нормальная галера, карусель между фотками не особо хочет переключаться (особенно если часть фото залита как фото, часть как файлы), выделить часть чтобы форварднуть уже не так удобно, автозагрузка не работает для них и размер 15Мб с зеркалки против 1-1.5Мб всё ещё не очень радостно качать. Разумеется варианта скачать в оригинальном размере зашакаленное фото нет и не предвидится

Клиент телеги жмёт, а потом ещё сервер телеги может пережимать. Например в тестовых настройках можно включить Large Photos и тогда они будут 2560px по широкой стороне... у тех, у кого включена эта опция, а включить её можно только на ПК сейчас. Остальные получат всё те же 1280px

У меня был кейс когда Я отправлял json просто перетаскиванием файла и после скачивания он был неликвиден. Когда отправил как док все было норм. С тех пор вышло много апдейтов и возможно сейчас ситуация уже изменилась.

Фото при желании можно залить без сжатия.

Точно так же и неполживые ребята из Купертино ничего не удаляют.

https://www.reddit.com/r/ios/comments/1cryayx/latest_ios_update_has_brought_back_some_pictures/

Соцсети никогда ничего не удаляют?!? Никогда такого не было и вот опять!

Запомните, детишки, если какой-то ресурс предоставляет вам бесплатный сервис, то товар - это вы, которым можно показывать рекламу и чьи данные можно продавать.

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

Верной дорогой идем в светлое будущее цифрового рабства, товарищи!

"Ничего нет нового под Луной, что было, то и будет" ©

"И наложит печать дьявол и число его сочти! Число 666!" ©

Пацаны, нас посчитали, наступает Апокалипсис!

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

Помню ещё во времена когда vk был vkontakte, vc был цукерберг позвонит, был кейс с удалением фоток.

Удаляешь фотку из ВК, но по прямой ссылке она всё равно остаётся доступной. Тогда это объясняли тем, что удаление это слишком ресурсоёмкое мероприятие. Тут в комментах более грамотные коллеги сообщают примерно то же самое, ссылаясь на концепцию SQL.

У яндекса точно так же, и они тем же объясняли. Было ещё во времена яндекс.фоток. Но с фотками это не к SQL относится, а к файловым системам - на удаление файла тратится время. Гораздо проще в базе пометить что такой фотки нет, и не отображать, а файл останется. Поэтому если уж надо хранить так, чтобы точно можно было удалить, то это делать на своих серверах, а там хоть вообще гарантированное удаление можно реализовать с перезаписью полной.

Не очень чистый эксперимент получается, сотрудники ВК тоже сидят на Хабре и могут вмешаться.

Они у меня во френдах сидят и мою страничку иногда читают... так что чистота экскремента заранее под вопросом.

Знать бы как еще эту скрытую инфу увидеть, было бы очень полезно

В этой главе герой понимает, почему соцсети бесплатны для конечных пользователей.

Синантроп, брахиоцефал, гемерофил, Лозинский, aidstest, диалогнаука.

Лозинский — дуб, AIDSTest — горбуха

Лет 5 назад у Вконтакта была адовая дырень в безопасности. Достаточно было ввести любое слово и по нему на отдельной вкладке выпадали все вордовские файлы в открытом доступе. Чего там только не было начиная от списков личных паролей и до разных конфиденциальных документов. Прикрыли относительно недавно, но всё это ранее там висело годами.

Т.е. обычный поиск по файлам в открытом доступе вы называете дыренью в безопасности? И как именно это пофиксили? Поломали поиск?

А до этого в емуле многие расшаривали целиком диск С

Буду очень волноваться, если еще через года два, не произойдет повторное открытие америки, что соцсети используют deleted=true, вместо удаления контента!

Кстати, при этом, вк, емнип, теряли какое-то количество картинок. Не помню, смогли ли они их восстановить.

ВК это вообще очень интересная система, там, например, очень старые посты невозможно комментировать или лайкать, уже не вспомню. Видимо они хранятся как-то иначе и доступны только на чтение

Да можно вроде комментарии ставить и лайки
Да можно вроде комментарии ставить и лайки

Ну у меня вроде комментируются публикации времён "стены Дурова". И лайк можно поставить.

Удалил тестовую запись.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории