:: Visual Foxpro, Foxpro for DOS
Индекс типа Binary
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Никто не проверял, насколько индексы типа Binary ускоряют процесс? Нужны ли они вообще? Или здесь то же самое, что и в дискусси

forum.foxclub.ru

Ничего не понял из описания по этому индексу про 3%. Когда приведет к замедлению, а кокгда к ускорению?

Их повышенная эффективность основана просто на меньшем физическом размере (в байтах) или есть что-то еще?




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Андрей Давыдов

Сообщений: 1411
Дата регистрации: 08.02.2003
2 Владимир Максимов

Вообще смысла не вижу в бинарном индексе: только разве на DELETED() для спец задач ковыряния в удаленных записях.
В хелпе недвусмысленно сказано что тег с фильтром FOR NOT(DELETED()) в vfp9 тоже оптимизируется.




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Aleksey Tsingauz

Сообщений: 407
Дата регистрации: 15.06.2004
Здравствуйте, Владимир!

Цитата:
Ничего не понял из описания по этому индексу про 3%. Когда приведет к замедлению, а кокгда к ускорению?

Имеется в виду, что если индекс используеся для оптимизации кокого-нибудь условия и 3% или более записей таблицы удовлетворяют условию, то оптимизация с использаванием BINARY индекса как правило быстрее. Если меньше чем 3% удовлетворяют условию, то оптимизация с использаванием BINARY индекса может быть медленнее, но незначительно. Трех процентная граница может понизиться по мере увеличения числа записей в таблице.

Цитата:
Их повышенная эффективность основана просто на меньшем физическом размере (в байтах) или есть что-то еще?

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

Алексей.




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Алексей, здравствуй!

Идеология Rushmore-оптимизации заключается в том, что на клиента СНАЧАЛА скачивается индексные тэги и выборка производится в них. И только потом качаются собственно отобранные записи. Это значит, что если размер индексного тэга (в байтах) больше чем размер (в байтах) записей НЕ удовлетворяющих условию выборки, то использование индекса будет тормозить выполнение запроса. Просто физически надо качать больше байт - сам индекс, да еще и почти все записи.

Это так было с "обычными" индексами.

Так вот, как в эту идеологию вписываются индексы типа Binary - я не понял. Почему логика работы с индексами типа Binary - прямо противоположная? Он что, хранит в себе только ссылки на записи НЕ удовлетворяющие условию индексного выражения?

В чем принципиальное отличие структуры индекса типа Binary от Regular? Как-то по другому строится индексное дерево? Есть ли в индексе типа Binary это самое дерево вообще? Откуда взялась граница в 3%?

В данном случае меня интересует в чем выгода использования индекса типа Binary по сравненнию с Regular по одному и тому же выражению. В частности, по Deleted(). Т.е. в обоих случаях мы имеем логическое выражение. Значит все правила модификации справедливы для обеих типов индексов. Или нет?




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Aleksey Tsingauz

Сообщений: 407
Дата регистрации: 15.06.2004
Цитата:
Идеология Rushmore-оптимизации заключается в том, что на клиента СНАЧАЛА скачивается индексные тэги и выборка производится в них. И только потом качаются собственно отобранные записи. Это значит, что если размер индексного тэга (в байтах) больше чем размер (в байтах) записей НЕ удовлетворяющих условию выборки, то использование индекса будет тормозить выполнение запроса. Просто физически надо качать больше байт - сам индекс, да еще и почти все записи.

Это так было с "обычными" индексами.
На самом деле весь тэг на клиента не качается. Однако, если все записи или почти все удовлетворяют условию, то оптимизации как таковой не получается, а ресурсы на сканирвание индекса затрачены. Если относительно малая часть записей удовлетворяет условию, то даже при очень большом индексе будет выигрыш.

Цитата:
Так вот, как в эту идеологию вписываются индексы типа Binary - я не понял. Почему логика работы с индексами типа Binary - прямо противоположная?
Я бы не сказал, что логика противоположная. Просто BINARY индекс это почти готовая битовая маска, часть работы, которая должна быть сделана для обычного индекса во время Rushmore, уже выполнена во время построения BINARY индекса.

Цитата:
Откуда взялась граница в 3%?
Из простого теста.

Цитата:
В данном случае меня интересует в чем выгода использования индекса типа Binary по сравненнию с Regular по одному и тому же выражению.
В педыдущем посте, я уже перечислил преимущества BINARY индекса.

Алексей.
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Цитата:
На самом деле весь тэг на клиента не качается.

С этого места поподробнее! Каким образом определяется список записей, которые надо отобрать, если не скачать весь индексный тэг? Он что, делает анализ индексного дерева в процессе его скачивания?

Цитата:
Просто BINARY индекс это почти готовая битовая маска, часть работы, которая должна быть сделана для обычного индекса во время Rushmore, уже выполнена во время построения BINARY индекса.

Можно это тоже расписать поподробнее. Что именно делает Rushmore-оптимизация при анализе индексного тэга?




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Aleksey Tsingauz

Сообщений: 407
Дата регистрации: 15.06.2004
Цитата:
С этого места поподробнее! Каким образом определяется список записей, которые надо отобрать, если не скачать весь индексный тэг? Он что, делает анализ индексного дерева в процессе его скачивания?

Можно это тоже расписать поподробнее. Что именно делает Rushmore-оптимизация при анализе индексного тэга?

Владимир, эта информация мне не принадлежит, может она где-то опубликована, а может и нет. Поэтому в глубокие подробности я вдаваться не буду. А если упростить, то Rushmore-оптимизация делает SEEK а потом SCAN WHILE. Это упрощение довольно грубое, но идея должна быть понятна.

Алексей.
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Ну, хорошо. Давай я распишу как я понимаю этот механизм.

-) Сначала скачивается целиком индексный тэг (не файл CDX, а именно нужный тэг из этого файла)
-) В нем организуется поиск нужных значений и формируется список записей, которые должны быть отобраны
-) С сервера скачиваются записи по кодам из сформированного списка

В чем, опять же, по моему мнению, может быть выигрыш индексов типа Binary.

-) Они физически меньше по размеру обычных индексов (меньший объем скачивается с сервера)
-) Поскольку индексы типа Binary никак не используются для визуализации информации и поиска ОДНОЙ записи, то, видимо, опускаются какие-то этапы их преобразования и связанные с этим флаги и ключи непосредственно в индексе
-) Поскольку индексы типа Binary содержат фактически только 2 значения ключа, то по сути - это уже готовый список записей. Уменьшается время сканирования индекса для поиска нужного СПИСКА записей.

Я не сильно ошибаюсь?




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Aleksey Tsingauz

Сообщений: 407
Дата регистрации: 15.06.2004
Цитата:
-) Сначала скачивается целиком индексный тэг (не файл CDX, а именно нужный тэг из этого файла)
-) В нем организуется поиск нужных значений и формируется список записей, которые должны быть отобраны
-) С сервера скачиваются записи по кодам из сформированного списка

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

Цитата:
В чем, опять же, по моему мнению, может быть выигрыш индексов типа Binary.

-) Они физически меньше по размеру обычных индексов (меньший объем скачивается с сервера)
-) Поскольку индексы типа Binary никак не используются для визуализации информации и поиска ОДНОЙ записи, то, видимо, опускаются какие-то этапы их преобразования и связанные с этим флаги и ключи непосредственно в индексе
-) Поскольку индексы типа Binary содержат фактически только 2 значения ключа, то по сути - это уже готовый список записей. Уменьшается время сканирования индекса для поиска нужного СПИСКА записей.
Довольно близко.

Алексей.
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Спасибо. Дальше попробую еще самостоятельно поковырять этот индекс.




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Цитата:
Сначала скачивается целиком индексный тэг (не файл CDX, а именно
нужный тэг из этого файла)
Cомневаюсь. Т.к. это бинарное дерево, то качать его целиком нецелесообразно.
Например мы ищем нечто (символьное для простоты) начинающееся на Я - root
элемент дерева содержит ключ "К" - это значит что нем надо идти по "правой"
ветви, а "левую" качать совершенно ненужно - ибо там никак не может
оказаться нашего "Я" - а это значит что в идеально сбалансированном дереве
мы экономим на скачивании сразу 50% объёма индекса! Ну и так далее -
скачивается тег только небольшими кусочками - и тут-же анализируется... А
вот Binary наверное не совсем так работает - если там хранится именно
битовая маска, то качать придётся целиком тег... Но он ессно будет
значительно меньше...
Цитата:
В нем организуется поиск нужных значений и формируется список
записей, которые должны быть отобраны
Да, но для этого не нужно
просматривать "заведомо неподходящие" ветви...
В остальном я думаю ты прав... Вообще надо будет этот вопрос подробнее
провентилировать - и на индекс более пристально посмотреть, и FileMon
попользовать и просто полномасштабный "реальный тест" провести (как в старой
ветке по поводу "полезности" тега по Deleted()).




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Вообще со структурой хранения данных в индексе я пока не разбирался.
Вот как раз сейчас ковыряюсь в способах физического хранения разных типов данных и потом посмотрю, что же происходит в индексных файлах. Правда тестить по сети негде




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Цитата:
Вообще со структурой хранения данных в индексе я пока не
разбирался.
Я тоже, тем более что описана она не то чтобу
супер-подробно (предполагается наличие некоторых абстрактных математических
знаний/пониманий - что такое бинарное дерево в частности...) В общем не для
полного новичка/профана написано.
Цитата:
Правда тестить по сети негде
Значит отпадает тест
"реальной работы", но FileMon и анализ структур остаються, они от сети не
зависят Анализировать FileMon-ом конечно надо и интенсивность обращений к
dbf/cdx и размеры запрашиваемых кусков... Не знаю есть ли какие средства
автоматического анализа, бо вручную эти логи просматривать конечно муторно и
долго




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Syberex

Сообщений: 1432
Откуда: Кострома
Дата регистрации: 19.01.2004
Цитата:
Я бы не сказал, что логика противоположная. Просто BINARY индекс это почти готовая битовая маска
Смысл видимо в том, что например для таблицы в 1000 записей создается область в 1000 бит,
каждый бит соответствует одной записи попорядку (номера записей в процессе работы не меняются ;))
Бит имеет значение 1, если запись удовлетворяет условию, иначе 0.
Получили битовую маску по условию, полная картина, остается только взять нужные записи...

Для 1'000'000 записей получим индекс весом 125 кб - круто ;)

(моя теория




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Я на выходных попробую "вскрыть" индекс типа Binary. Напишу, что получится. Сейчас занимаюсь "вскрытием" разных типов полей.




------------------
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Господа разрешите и мне поучаствовать в дискуссии.

Мне кажется, что идеология понимания Вл. Максимова близка к истине, на чем основывается такая уверенность, давайте вспомним о структуре хранения файлов (ведь CDX это файл) и как операционная система читает файл.
Предположим, что надо выбрать записи из таблички по оптимизируемому условию, что делает фокс
1. Просит ОС наити CDX файл, ОС определяет пул абсолютных адресов расположения файла и начинает считывать файл в ОЗУ (по кластерам или блокам или секторам зависит от ОС) для того, что бы передать в пакеты сети; в свою очередь ОЗУ тоже общается не байтами, а страницами, и в этот момент ОС ни о каком индексном теге понятия не имеет, таким образом тезис о считывании именно тэга или даже куска дерева кажется сомнительным (если бы в заголовке индексного файла лежали адреса фрагментов CDX, то тогда качать индексный тег было бы возможным, но в этом случае запись файла в другое место должна изменять и адресацию)
2. Таким образом CDX файл оказывается на клиенте, где его потрошат на предмет оптимизации, после того как были определены записи (читай относительные адреса в байтах) удовлетворяющие условию, передается запрос на выборку записей из таблицы в виде дай кусок файла с адреса такого со смещением таким, здесь история с чтением кластеров и страниц повторяется, но в пакет сети поступают только данные с запрошенными адресами и в результате на клиенте оказывается временный файл, нарезанный по условию оптимизации. Это же касается и фильтра на таблицу.

PS может моё понимание устарело, тем не менее вроде вытекает из работы ОС




------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Устарело, устарело
См. АПИ функции файлового доступа - там всегда запрашивается "кусок файла",
и программе (в случае фокса это программа написанная на C++) глубоко "до
фени" как физически хранится файл, и как его ОС считыват - побайтно или
кластерами по 32Кбайта Это уже задача кэша операционки - не дёргать диск
если последующее обращение выбирает данные из того-же кластера что и
предыдущее.
Очень советую посмотреть лог обращений к файлам для чего скачай и запусти
утилиту FileMon. Там отлично видно когда файл открывается, когда и какими
порциями он читается. Учти что доступ к файлам организован не
последовательно а "произвольно" - т.е. в любой момент можно прочесть любой
фрагмент файла, и для этого вовсе не требуется предварительно считывать весь
файл с диска (ну или всю начальную его часть до той что нас заинтересовала)




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Утилиту скачал спасибо, завтра посмотрю.
Да я и не говорил, что идет последовательное считывание файла до нужного места, а говорю о том, что изначально неизвестно в каком месте физически распологаются узлы и листья индекса, для поиска необходимых записей, на мой взгляд есть два пути:
1. Налету вычислять и формировать массив или вектор (в математическом понимании) адресов физического расположения записей, что как я понимаю связано с интенсивным трафиком, те фокс говорит дай мне корневой узел я вычислю адрес узлов индекса, затем дай узелы индекса я вычислю соответствующие листья и затем дай мне листья я в этих листьях буду искать адреса записей (и так для всех индексов и всех таблиц участвующих в оптимизации)
2. Или дай мне весь файл CDX я вычислю всё что надо сделаю обьединения и пересечения и запрошу уже готовый массив адресов


А то что чтение происходит кластерами, так от этого никуда не денешься - так устроен контроллер HDD (вот ему то действительно всё до фени) и кажущееся чтение куска на самом деле результат действия ОС или аппаратного преобразования IDE или SCSI.




------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Цитата:
говорю о том, что изначально неизвестно в каком месте
физически распологаются узлы и листья индекса
Естественно.
Цитата:
те фокс говорит дай мне корневой узел я вычислю адрес узлов индекса,
затем дай узелы индекса я вычислю соответствующие листья и затем дай мне
листья я в этих листьях буду искать адреса записей (и так для всех индексов
и всех таблиц участвующих в оптимизации
Именно так (упрощённо
конечно) всё и происходит.
Цитата:
дай мне весь файл CDX
Нет, не нужен ему весь файл (и даже
весь тег целиком).
Вот слегка урезаный (только доступ к таблице и индексу и только от самого
фокса - VFP9 Public Beta, но это несущественно) лог FileMon-а для выборки из
таблицы в 10000 записей всего 1 записи (по первичному ключу). Тег всего
один - как раз по полю первичного ключа. Размеры файлов видны, комментарии
прилагаются:
IRP_MJ_CREATE C:\table1.DBF SUCCESS Attributes: N Options: Open
FASTIO_QUERY_STANDARD_INFO C:\table1.DBF SUCCESS Size: 350361 размер
dbf-а

IRP_MJ_READ C:\table1.DBF SUCCESS Offset: 0 Length: 2048 считали
заголовок dbf-а и первую запись - стандартная процедура при любом типе
открытия таблицы - явном или неявном

IRP_MJ_CREATE C:\table1.CDX SUCCESS Attributes: N Options: Open
FASTIO_QUERY_STANDARD_INFO C:\table1.CDX SUCCESS Size: 45568 размер
cdx-а

IRP_MJ_READ C:\table1.CDX SUCCESS Offset: 0 Length: 8192 считали
корневой узел CDX-а, узлы с инфой об имеющихся тегах и очевидно корневой
узел нашего единственного тега (может и ещё несколько влезло)

FASTIO_READ C:\table1.CDX SUCCESS Offset: 25088 Length: 512 считали
какие-то более глубокие узлы

FASTIO_READ C:\table1.CDX SUCCESS Offset: 14336 Length: 512 и ещё раз
считали более глубокие узлы

FASTIO_CHECK_IF_POSSIBLE C:\table1.DBF SUCCESS Read: Offset: 104960 Length:
512
FASTIO_READ C:\table1.DBF SUCCESS Offset: 104960 Length: 512 а теперь
собственно забрали интересующую нас запись из таблицы

Надеюсь тут всё прозрачно... Никакого чтения 45Кб индекса (напомню там всего
1 тег!) не происходит. размеры порций чтения по 512 байт очевидно некая
"оптимизация" фокса - он не "точно нужный кусочек" считывает, а заодно весь
"блок" (хотя как видно фокс не учитывает то что ОС может считывать данные по
кластерам большим чем 1 сектор - ну да там уже кэширование самой ОС
поможет)... Бывают AFAIK и иные схемы доступа (для сетевых дисков в
частности) но и там никогда не скачивается весь тег целиком...




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Индекс типа Binary
PaulWist

Сообщений: 14601
Дата регистрации: 01.04.2004
Провел эксперимент на сетевом диске, таблица 700000 записей, первичный индекс по int полю, сделал Select id from Table where id < 1000 or id > 699000 это что бы искал в разных ветвях индекса, ну результат понятно 2000 записей

вот Log

FASTIO_READ D:\wist\sax\comlog.CDX FAILURE Offset: 11071488 Length: 4096 - попытка прямого чтения неудачна
IRP_MJ_READ D:\wist\sax\comlog.CDX SUCCESS Offset: 11071488 Length: 4096 - чтение набора равного пакету сети
IRP_MJ_READ* D:\wist\sax\comlog.CDX SUCCESS Offset: 11071488 Length: 4096 - IRP_MJ_READ*не очень понятно почему обозначено звёздочкой
FASTIO_READ D:\wist\sax\comlog.CDX FAILURE Offset: 11075584 Length: 4096
IRP_MJ_READ D:\wist\sax\comlog.CDX SUCCESS Offset: 11075584 Length: 4096
IRP_MJ_READ* D:\wist\sax\comlog.CDX SUCCESS Offset: 11075584 Length: 4096
FASTIO_READ D:\wist\sax\comlog.CDX FAILURE Offset: 11079680 Length: 4096
IRP_MJ_READ D:\wist\sax\comlog.CDX SUCCESS Offset: 11079680 Length: 4096
IRP_MJ_READ* D:\wist\sax\comlog.CDX SUCCESS Offset: 11079680 Length: 4096
IRP_MJ_READ* D:\wist\sax\comlog.CDX SUCCESS Offset: 11141120 Length: 65536
IRP_MJ_QUERY_INFORMATION D:\wist\sax\comlog.dbf SUCCESS FileStandardInformation

что видим:
1. действительно, вычисление адресов происходит налету причем первоначальное чтение происходит как будто запрос произведен с локальной машины
2. повторное чтение нарезается по размеру пакета сети
3. и предпоследняя строчка видимо - сама матрица адресов записей
4. последняя строка заголовок полученного файла
что самое удивительное для меня, так это то что хотя сказали фоксу Select ни одна запись из dbf не выбрана

Затем говорю Scan по выбранному курсору, что бы посмотреть как физически выбираются записи
вот кусок Log-а

IRP_MJ_READ D:\wist\sax\comlog.dbf SUCCESS Offset: 218165248 Length: 32768
IRP_MJ_READ* D:\wist\sax\comlog.dbf SUCCESS Offset: 218165248 Length: 4096
IRP_MJ_READ* D:\wist\sax\comlog.dbf SUCCESS Offset: 218234880 Length: 65536 - данные лежат подряд
FASTIO_READ D:\wist\sax\comlog.dbf FAILURE Offset: 218198016 Length: 4096
IRP_MJ_READ D:\wist\sax\comlog.dbf SUCCESS Offset: 218198016 Length: 4096 - здесь пошли разрывы в потоке файла
FASTIO_READ D:\wist\sax\comlog.dbf FAILURE Offset: 218202112 Length: 4096
IRP_MJ_READ D:\wist\sax\comlog.dbf SUCCESS Offset: 218202112 Length: 4096
FASTIO_MDL_READ D:\wist\sax\comlog.dbf FAILURE Offset: 218206208 Length: 8192
FASTIO_READ D:\wist\sax\comlog.dbf FAILURE Offset: 218206208 Length: 8192
IRP_MJ_READ D:\wist\sax\comlog.dbf SUCCESS Offset: 218206208 Length: 8192
FASTIO_MDL_READ D:\wist\sax\comlog.dbf FAILURE Offset: 218214400 Length: 20480
FASTIO_READ D:\wist\sax\comlog.dbf FAILURE Offset: 218214400 Length: 20480
IRP_MJ_READ D:\wist\sax\comlog.dbf SUCCESS Offset: 218214400 Length: 20480
IRP_MJ_READ* D:\wist\sax\comlog.dbf SUCCESS Offset: 218300416 Length: 65536
FASTIO_MDL_READ D:\wist\sax\comlog.dbf FAILURE Offset: 218234880 Length: 32768

В итоге видим, что как бы мал кусок данных не был он нарезается под размер пакета сети, почему-то всё время идут неудачные попытки прямого чтения; чтож технология доступа к индексу несколько изменилась я действительно немного отстал

PS жду вашей интерпритации представленых данных




------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 18 (Гостей: 18)

© 2000-2024 Fox Club 
Яндекс.Метрика