информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hacking
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Есть такая структура B-Tree называется 23.05.05 19:07  Число просмотров: 4185
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Дает гарантированное логарифмическое время (для худшего случая) для операций поиска/вставки/удаления и оптимизирована для хранения баз данных на внешних носителях с посекторным чтением. А если еще и закешировать хотя бы пару уровней в этом дереве, то вообще мгновенная выборка получается.

> > Как по мне, то лучше сделать вообще независимые
> серийник и
> > код пополнения и все соответствия держать в базе. То
> есть
> > функция то есть, но в целом она выглядит примерно так:
> > код_пополнения = select код_пополнения from база where
> > сер_нум = запрошенный_сер_нум
> > Обычная табличная функция.
> Я в оптимизации систем баз данных не большой спец, но мне
> кажется...
> что для этого слишком большая вычислительная и дисковая
> мощность необходима.

Будем считать, что в каждый момент времени активно ~10-100 миллионов карточек. Если на каждую карточку нужно порядка 4 байт на серийник и 6 байт (14 десятичных разрядов) на код пополнения. Пусть оверхед на хранение - 200% (до фига на самом деле, ну да ладно - мне не жалко) итого 32 байта на каждую запись. Для хранения ВСЕЙ базы в памяти достаточно от 320 метров до 3.2 гига ОЗУ. Это вполне реально даже на персональных тачках (не думаю, что у КС нет денег на High-end сервак). Самая частая операция - поиск - будет выполняться вообще без доступа к диску.

> 1. запросы на верификацию кода пополнения.

Логарифмическое врямя (для худшего случая) поиска по дереву

> 2. извлечение суммы пополнения

В ноде для кажного значения хранится вся необходимая информация

> 3. установка статуса "активировано"

См. п. 2

> 4. Добавление новых карточек и переиндексация после

Логарифмическое (для худшего случая) время добавления в дерево

> добавления.
> 5. Очистка не валидных карточек из базы (просроченная дата
> активации, например).

Логарифмическое (для худшего случая) время удаления.

> 6. Отслежевание всех транзакций по базе с целью

Это никак не зависит от алгоритма сопоставления серийника с кодом пополнения

> предотвращения подбора кодов недобросовестными сотрудниками
> или несанкционированного доступа.

См. п. 6

> добавлять можно еще.

Следует учитывать также, что каждая нода может входить более, чем в одно дерево/список (для поддержания возможности поиска по разным ключам, но исключить необходимость переиндексации)

Посмотрите на индекс гугля и поймете, что хранение десятков-сотен миллионов целочисленных пар ключ-значение - вообще детская задача в современном вычислительном мире.
<hacking> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach