Azure table delete pattern - удалить старые предметы

Question

Я работаю с таблицей Azure (хранилище), чтобы хранить информацию о веб-сайтах, с которыми я работаю. Итак, я планировал эту структуру:

1. раздела Key - имя домена
2. Row ключ - Веб-страница адрес
3. Действителен до (дата время) - после этой даты, запись будет удалена.
4. Другие важные данные здесь ...

тех столбцов будут сохранены в таблице называется как адрес веб-сайта (например, «cnn.com»).

У меня есть два основных варианта использования (от низкого до низкого): 1. Проверьте, действительно ли URL «x» находится в таблице - найти по сочетанию ключа раздела и ключа строки - очень эффективно. 2. Удалить старые данные - удалить все истекшие данные (в соответствии с столбцом «Действителен до»). Эта операция происходит каждую ночь и, возможно, удаляет миллионы строк - очень тяжелая.

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

Я также беспокоюсь о создании «горячих точек», что сделает меня низкой производительностью. Это потому, что ключ раздела. Я ожидаю, что через несколько часов я запрошу больше вопросов для конкретного домена. Это сделает эту точку доступа раздела и ударит мою производительность. Чтобы этого избежать, я решил использовать хеш-функцию (по URL-адресу), и результатом будет «ключ раздела». Это хорошая идея?

Я также думал о другом пути реализации, и это выглядит, как у них есть некоторые проблемы:

• Сохранение строк в таблице, названые с датой удаления (например, «cnn.com-1-1-2016»). Это дает нам отличную производительность. Но плохой опыт поиска (строка может существовать более чем в одной таблице, например «cnn.com-1-1-2016» или «cnn.com-2-1-2016» ...).

Какое правильное решение для моей проблемы?

Answer 1

Вы видели Azure Table Storage Design Guide? В нем описываются принципы и шаблоны для разработки табличных решений в масштабе. Для горячих точек взгляните на анти-шаблон prepend/append для получения дополнительной информации. Здесь все ваши операции происходят в одном разделе, что предотвращает добавление дополнительных ресурсов. Для этих типов сценариев вы получите более высокий масштаб, если вы можете распределить операции между разделами.

Answer 2

1. Предположим, у вас есть сайт https://www.yahoo.com/news/death-omar-al-shishani-could-mean-war-against-203132664.html?nhp=1. Вы можете сохранить PK как domainName + "/ news /" + 2 буквы адреса страницы, сводка https://www.yahoo.com/news/de. РК - другая часть полного адреса. Это разделит ваш доменный раздел на около 1000 разделов. Если этого недостаточно - используйте 3 первых буквы в ПК.

2. Удалите устаревшие данные каждые 15 минут (создайте для него отдельную услугу). Ваши миллионы станут десятками тысяч. Или сохранить меньше данных (2 недели вместо месяца for.ex.). И не забывайте оптимизировать удаление (получить только PK и RK, обновить ETag до «*», удалить как DynamicTableEntity, если возможно, пакет).