Нужна БД для сайта-биржи.
24 марта 2009 в 19:14

Нужна БД для сайта-биржи.

Нужна БД для сайта-биржи.БД будет представлять из себя массив из примерно 5млн позиций предложений продукции предприятий.
Основные критерии БД:объем,надежность базы,быстрота поиска,
интерфейс,возможность работы при примерно100 одновременных обращениях-запросах,возможность "органичной "привязки к сайту.
Сайт,который можно рассмотреть как упрощенный аналог планируемого к созданию можно посмотреть здесь: birga.net
Хочу услышать мнения,предложения,советы,как лучше и на какой основе сделать.

336
Комментарии (14)
  • 25 марта 2009 в 14:08 • #
    Тимофей Цветков

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

  • 26 марта 2009 в 13:57 • #
    Евгений Панин

    Вас интересует вопрос выбора СУБД или Вы хотите найти исполнителя для создания подобного сайта?

  • 10 марта 2014 в 17:23 • #
    Николай Андрейчиков

    Новый способ хранения персональных данных

    В базе данных персональные данные должны сохраняться в следующем виде:
    1) Вымышленные персональные данные, которые по внешнему виду не отличимы от действительных персональных данных. Например, реальная фамилия Петров может храниться в виде фамилии Медведевский или Obama или любой другой. Размер реальной фамилии и размер вымышленной фамилии между собой никак не связаны.
    2) Набор целых чисел от 1 до 65535 в количестве, равному размеру реальных персональных данных. Например, для фамилии Петров - это 6 чисел, так как в фамилии Петров 6 букв, примерно таких: 111, 75, 71, 29, 100, 211.
    Больше ничего в базе данных не должно сохраняться.
    Для восстановления реальных данных из вымышленных необходимо в оперативной памяти компьютера хранить алфавит - перечень символов, используемых для отображения персональных данных. Максимум - это 65535 символов в кодировке Unicode. Порядок следования символов в алфавите имеет первостепенное значение. Набор чисел в приведенном выше примере для фамилии Петров - это связь между адресами букв реальной фамилии Петров в алфавите и адресами букв вымышленной фамилии Медведевский в алфавите. Алфавит отличается от шрифта тем, что символы в алфавите различаются только по коду и порядок следования символов произвольный. Начертания символов не имеет никакого значения для алфавита. В шрифте начертания символов имеет первостепенное значение и порядок следования символов единственный.
    Адреса букв в алфавите и реальные буквы между собой никак не связаны.
    Если хакеры украдут из базы данных вымышленную фамилию Медведевский или Obama и украдут набор чисел 111, 75, 71, 29, 100, 211, то восстановить реальную фамилию Петров не смогут, так как отсутствует алфавит. А украсть алфавит из оперативной памяти практически невозможно.
    Если изменить в алфавите порядок следования символов, то это будет уже другой набор чисел для фамилии Петров. Можно время от времени изменять алфавит и заменять наборы чисел в базе данных для персональных данных. Вымышленные персональные данные можно не изменять.
    Как видите, украсть персональные данные невозможно, так как их попросту нет. Кража вымышленных персональных данных в этом случае бессмысленна. Под персональными данными мы понимаем в том числе пароли, логины, аккаунты и т.п.
    Алгоритм отображения информации.
    Алфавит - перечень символов, встречающихся в текстах. Каждый символ в алфавите встречается только один раз. Алфавит содержит не только прописные и строчные буквы, но символы знаков препинания, пробел, символы перевода каретки, символы новой строки и т.п. Каждый символ в алфавите имеет адрес, который изменяется от 1 - первый слева символ в алфавите, до N - последний слева символ в алфавите.
    Рассмотрим пример.
    Пусть имеем два слова: Путин, Медведев. В этих словах имеются следующие символы: П, у, т, и, н, М, е, д, в. Этот набор символов называется собственным алфавитом слов Путин и Медведев.
    Задача: Найти алгоритм отображения слова Путин через слово Медведев и алгоритм восстановления слова Путин из слова Медведев.
    Решение: Возьмем алфавит, состоящий из всех символов русского и английского языка, знаков препинания, пробела. Всего 190 символов, т.е. N = 190. Порядок символов в алфавите - случайный.
    Запишем собственный алфавит в следующем виде:
    17=П, 100=у, 34=т, 35=и, 144=н, 190=М, 88=е, 66=д, 1=в
    П=17, у=100, т=34, и=35, н=144, М=190, е=88, д=66, в=1
    В первой строке указаны адреса символов собственного алфавита в общем алфавите. Во второй строке указан собственный алфавит.
    Для преобразования буквы "П" в букву "М" сравним адреса букв "П" и "М". Это числа 17 и 190. Для отображения буквы "П" через букву "М" необходимо к числу 17 прибавить число 190-17=173 и по адресу 190 считать букву "М". Число 173 запишем в вектор на первое место, так как это число отображает первые буквы.
    Для отображения буквы "у" через букву "е" сравним адреса букв "у" и "е". Это числа 100 и 88. Для отображения буквы "у" через букву "е" необходимо к числу 100 прибавить неизвестное число x, такое чтобы получилось число 88. Решаем уравнение 100 + x = 88, от

  • 26 марта 2009 в 23:20 • #
    Виталий Тренкеншу

    Как я понял, основными требованиями к СУБД будут масштабируемость (100 одновременных пользователей) и быстродействие на больших объёмах данных. Этим требованиям идеально удовлетворяет Oracle. Минус - дорого: как лицензии на СУБД, так и PL/SQL-разработчики.

  • 14 июля 2009 в 13:57 • #
    Дмитрий Клецких

    не так чтоб очень и дорого... не дороже продукции от Microsoft... дьявол в мелочах... а вот PL/SQL - это да... за хлеб и воду работать не будут... )

  • 27 марта 2009 в 21:56 • #
    Артур Гильт

    Соглашусь с Тимофеем Ц. PostgreSQL будет идеальным выбором. OpenSource решение это только плюс.

  • 1 апреля 2009 в 07:26 • #
    Максим Семенкин

    FirebirdSQL не сильно раскрученная промышленного уровня БД. OpenSource
    Непонятно про какой поиск идет речь. Если про полнотекстовый, то скорее всего ни одна из БД не поможет вам в полной мере решить этот вопрос - нужно будет делать отдельный поисковый сервис.

  • 3 мая 2009 в 06:37 • #
    Z Z

    Если деньги позволяют - конечно лучше выбрать Oracle, как полноценное продакш-решение серьёзного уровня.

    Если денег не много - PostgreSQL будет замечательным выбором.

    Firebird, Interbase & Yafill - это почти одно и то же. У этого семейства не самый лучший и не самый быстрый оптимизатор запросов, поэтому для приложений продакшн-уровня я бы не посоветовал.

    MySQL - хорошая штука для простых запросов. На простых запроса даже PostgreSQL обгонит, но на сложных запросах и больших объёмах данных - PostgreSQL будет круче.

    Так же, как уже упомянали коллеги, Вам, наверное, нужен партишанинг и, возможно, даже кластеризация - в этом опять же, Oracle, конечно лидер - готовьте кошелёк =)

  • 5 июня 2009 в 15:27 • #
    Dmitry Stefanovskiy

    Предлагаю посмотреть немного в другую сторону.

    Не важно какая БД.
    Можно использовать ngnix ......

    Для этого важно понять 100 - одновременных обращений к одной позиции или нет. От этого зависит способ переадресации запроса на конкретный "подсайт".
    (Как это сделано в большинстве хостингов.)

    Если же у позиций есть некоторая структура которая позволяет сделать несколько сайтов, на которые ngnix будет отправлять выполнять долгую транзакцию (принимать заказ ).
    Соответственно на на одной машине можно ставить почти статичный прайс лист с функциями сравнения, а формирование сделок отправлять уже на другие сервера.

    http://www.opennet.ru/openforum/vsluhforumID8/4382.html

  • 9 июля 2009 в 09:03 • #
    Алексей Д

    mysql - неплохо, шустро, но на современном уровне слабовато, и уже не совсем бесплатно (последние версии уже распространяются платно)

    mssql - вполне бодро, но платно, ограниченно тока на win платформе. зато удобство управления и вполне стабильно (наскока может быть стабильно на win)

    firebirdsql - забудте про него. для ваших условий это не подойдет ни разу для ваших задач.

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

    postgresql - вполне разумный выбор в вашем случае. медленнее mssql, но богаче по функционалу, стабильнее и т.п. многоплатформенна, и бесплатна.

  • 14 июля 2009 в 14:02 • #
    Дмитрий Клецких

    Oracle задачку на раз-два решит... Если хотите на перспективу работать, то лучше с ним... потратитесь на "движок", зато проблем дальше не будет... В сторону аналогов от Microsoft или IBM смотреть не советую... OpenSource тоже хороши... но это другой класс СУБД... ничего "корпоративного" на них не построите...

  • 23 июля 2009 в 16:27 • #
    Александр Губарик

    Для довольно быстрой разработки могу предложить www.nsgsoft.ru. Можно использовать базовую часть как обертку для MsSQL. Работа с объектами высокого уровня позволяет съэкономить время на работе с БД.

  • 6 мая 2010 в 19:18 • #
    Андрей Прокофьев

    Хотелось бы уточнить, Вам нужна база данных или решение? Сегодня практически любая база дынных способна работать с таким объемом данных.
    Могу предложить нашу платформу, которая позволит не просто создать сайт, но и интегрировать его с другими системами или биржами. http://www.softlogic.ru/p/archimedes. В ней, кроме всего прочего, решаются вопросы кэширования, масштабирования, ограничения доступа и др.

  • Желаете ознакомиться с остальными комментариями или оставить свой? в сеть, чтобы получить полный доступ к функционалу Профессионалов.ru! Еще не участник сети?