18 марта 2009 в 06:50

Нужна БД для сайта.

Здравствуйте!
Нужна БД для сайта-биржи.
В ней будет содержаться информация о предложениях (складских остатках)более,чем 2000предприятий.Всего более 5млн позиций продукции.
1.подскажите,пожалуйста, на какой основе лучше ее делать?
2.Какие требования обязательно указасть в ТЗ для такой базы для исполнителя?
3.Сколько может стоить написание такой базы?И сколько по времени займет?
Заранее благодарен.

239
Комментарии (49)
  • 18 марта 2009 в 14:27 • #
    Владимир ЧЕРНЫШЕВ

    Типа сайта e-slovar с безграничным числом позиций?

  • 18 марта 2009 в 14:40 • #
    Антон Казаков

    Насколько я понимаю, под "базой" понимается сама БД и интерфейс управления её содержанием :)

    Так вот такая "база" может быть сделана на многих разных SQL-серверах. Всё зависит от нагрузки на неё, потому как просто сделать запрос по пяти миллионам записей может и MySQL, даже достаточно быстро, если у него есть все нужные индексы по полям. Вопрос в том, как часто и обширно эта "база" будет пополняться, как часто и много к ней будут обращаться за выдачей результатов запросов, и насколько это будут сложные запросы - если обычный SELECT по пяти миллионам записей в одной таблице - это не слишком долго, но вот если к этой таблице идёт INNER JOIN, тогда количество записей уже увеличивается, а если нужен будет LEFT JOIN (хотя такой ситуации лучше, конечно, избегать при подобных количествах записей), то уже упомянутый MySQL точно не сдюжит ни за что. Зато Oracle сдюжит.

    Кстати, есть ещё отличная штука - Sphinx. Тоже очень быстро ищет по любым данным, в том числе и из БД доставаемым. Только его индекс должен в полном объёме помещаться в оперативную память сервера :)

  • 18 марта 2009 в 19:25 • #
    Александр Лещинский

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

  • 18 марта 2009 в 23:54 • #
    Антон Казаков

    Нет-нет, я всё же надеюсь, что умею его готовить ;) Ведь я с ним работаю очень и очень плотно последние лет 5. Не знаком с новшествами последних версий, каюсь, но 4-я и первые из 5-х всё-таки требуют очень уж грамотного и буквоедского подхода к оптимизации запросов. Иначе тормозят даже на несчастных 10-ти миллионах записей в результате какого-нибудь JOIN-а. Под "тормозят" я понимаю секунду-другую обработки, если что :)

    Да, если оптимизировать запросы, оптимизировать хранение данных (чтоб уменьшить количество JOIN-ов в результате получения некоторой избыточности, например) и понаделать индексов, то с миллионами записей вполне можно справляться, а где-то их и не понадобится. Но Oracle в любом случае быстрее ;)

  • 19 марта 2009 в 02:16 • #
    Александр Лещинский

    33 раза не соглашусь. Оракл в общем случае не быстрее, а в частном, при неаккуратном написании кода - просто ужасен в производительности. Ораклевый плюс - в надежности (в отличие от, где InnoDB еще куда ни шло, а MyISAM только для последователей Мазоха). И, BTW, 5.1.* значительно лучше 5.0 (про 4 я вообще говорить не буду)

  • 19 марта 2009 в 08:15 • #
    Антон Казаков

    Спорить не буду :) С Орклом имел дело только "постольку, поскольку", а MySQL 5.1.* вообще не юзал. Ну а раз он настолько лучше, то я уже даже не знаю, какие ему альтернативы можно предложить ;) Он же ещё и распространён и доступен (в плане того, что разбираются) гораздо большему количеству разработчиков, нежели большинство других.

  • 20 марта 2009 в 13:24 • #
    Виктор Семенов

    Мой опыт общения с ORACLE: Он всегда предсказуем, в отличие от...
    Любую мощную машину и любой движок DBMS можно загнать в угол неаккуратным написанием кода. ORACLE не исключение. Однако, на Оракле можно делать быстрые приложения, и добившись необходимого быстродействия, быть уверенным, что с ростом объемов скорость упадет на проценты, а не в разы. Ну и надежность, что есть то есть.

  • 18 апреля 2009 в 22:17 • #
    Дмитрий Олейник

    оракл штука очень капризная
    надёжность ... на моих глазах этот зверь падал

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

    Interbase выйграл у Oracle8i

  • 8 апреля 2009 в 12:13 • #
    Владимир Светашев

    Антон, и что интересно, даже и не SQL-серверах это можно реализовать.

  • 8 апреля 2009 в 12:22 • #
    Антон Казаков

    Хм... А на каких тогда? :) Просто файлами, самому что-то типа СУБД соорудить? :)

  • 18 марта 2009 в 14:51 • #
    Анатолий Акишин

    Ну что лучше это филосовский вопрос я бы писал на SQL но получилось бы грамозко (просто я его знаю :) ) в ТЗ указывать как можно подробней что вы хотите видеть если нужны расчеты то какие и тд.. представте что вы уже работаите с этой базой. Потом проблем меньше а если написать хочу машину это не значит что Вам дадут лимузин, а не пластмасовую машинку.сроки и цена это уже другое слишком много факторов влияет.

  • 18 марта 2009 в 15:12 • #
    Геннадий Беседин

    Рассмотрите вариант реализации на 1С:8.2.
    Достоинства:
    - автоматически получается WEB-интерфейс
    - гибкое наращивание функционала
    - потянет по производительности
    Недостатки:
    - авангардное решение
    - мало специалистов
    - придется писать код

  • 19 марта 2009 в 19:59 • #
    Сергей Сергин

    Версия 8.2 уже вышла? Пару дней тому назад я был на их сайте, откровенно говоря весьма впечатлён описанными возможностями, но разве вживую это уже можно пощупать?

  • 19 марта 2009 в 20:38 • #
    Геннадий Беседин

    Вполне.
    К примеру, 1С:Сеть (провайдер EDI) уже реализовал ВЭБ-сервис через 8.2.
    Выглядит очень впечатляюще.
    Какой вывод?
    Не ждите финального релиза платформы.
    Качните, к примеру, 1С:Архив с сайта 1С, бесплатно.
    Вообще 1С взорвет рынок с выходом 8.2. Этому будет способствовать автоматическая дуальность интерфейса (ваша база АВТОМАТИЧЕСКИ представляется в Интернете), многоплатформенность. Прямая аналогия с Lotus/Domino, хотя 1С и тут превзошел "учителя", в частности, по автонастройке под ВЭБ. Это мое частное мнение.

  • 19 марта 2009 в 21:09 • #
    Сергей Сергин

    Сейчас обсуждение выйдет за рамки заданного автором темы, но одно сообщение, пожалуй оставить смысл имеет.
    Как приверженец открытых решений и обладатель опыта работы в продукцией 1С я с нетерпением ожидал момента, когда можно будет отказаться от жёсткой привязки к одной платформе. Именно потому был так обрадован прочитанным про 1С 8.2.

  • 19 марта 2009 в 21:58 • #
    Геннадий Беседин

    Ну и хорошо. Посему завершаем веточку.

  • 18 марта 2009 в 15:15 • #
    Максим Еременко

    ИМХО один из лучших вариантов - Postgres. С одной стороны открытый проект (т. е. лицензии бесплатны), с другой мощная штука, кластеризуется и т. п.

  • 18 марта 2009 в 19:22 • #
    Александр Лещинский

    Вот только создание и ведение (правильные) этого дела - достаточно дорогое удовольствие (в сравнении с...)
    Без хотя-бы литературного максимально полного описания задачи я бы не рискнул начинать разговор о платформе

  • 18 марта 2009 в 16:14 • #
    Андрей Стародубцев

    А на какой железке будет крутиться, уже определились?

  • 18 марта 2009 в 19:23 • #
    Александр Лещинский

    Это, по моему, вовсе НЕ первый вопрос, на который надо найти ответ

  • 18 марта 2009 в 19:28 • #
    Александр Лещинский

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

  • 18 марта 2009 в 21:08 • #
    Виктор Бирюков

    Здравствуйте, коллеги.
    По моему скромному мнению перед написанием ТЗ на какую либо систему необходимо понять масштабы бедствия (предполагаемый объем базы, количество серверов, количество запросов в ед времени и т.д.) Кроме того немаловажным аспектом является наличие в компании или на рынке труда количество и оклады специалистов способных поддерживать данную систему. При заказе разработки такой БД не стоит озадачиваться стоимостью лицензий на СУБД (ИМХО) ведь Вам нужна надежная система, а не сделанная "на коленке" поделка, работающая через раз.

  • 19 марта 2009 в 00:42 • #
    Борис Вольфман

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

    А в соответствии с требованиями подбирать сервер, SQL-сервер и т.п.

  • 19 марта 2009 в 21:26 • #
    Виктор Бирюков

    Борис. "Перед написанием ТЗ" я имел ввиду сформулировать требования в голове, а затем просто изложить их на бумаге. Когда требования формируются в процессе написания ТЗ приходится очень часто переписывать отдельные части ТЗ и в результате получается "лоскутное одеяло", в котором частенько не совпадают требования к разрабатывамой системе в различных частях. Кстати: привлеките к написанию ТЗ и договора с подрядчиком компетентного программиста, которому, по Вашему мнению эту систему предстоит поддерживать. Это поможет избежать зависимости от разработчика системы, ускорить написание ТЗ и проблем при разворачивании системы на другом сервере.

  • 19 марта 2009 в 22:10 • #
    Борис Вольфман

    Виктор.
    То, что Вы называете сформулировать требования в голове - называется определить цели проекта (программного продукта).
    Цели должны быть просты и понятны Заказчику, а теория говорит: измеримы.
    То есть в конце проекта, когда все сделано, чтобы можно было ответить на вопрос - цели достигнуты, можно деньги получать?
    Каждое требование должно детализировать цели проекта.
    После того, как ТЗ написано - обязательно его необходимо согласовать с программистом (архитектором), тот должен расписаться, что ТЗ реализуемо, еще с тестировщиком - ТЗ должно быть проверяемо (тестируемо).
    Например, если Вы в ТЗ пишете, Ваша система должна обслуживать 100000 пользователей и время реакции д.б. не менее 10 секунд, то в ТЗ должен быть определен алгоритм проверки требования - нагрузочные испытания.
    Для поддержки системы также должны быть сформулированы требования и согласованы с программистом, который будет ее поддерживать.
    Например: в системе должен вестись журнал, позволяющий локализовать проблему инженеру по поддержке, а в сложных случаях - разработчик обязан получив журнал дать объяснение проблемы.
    А самое главное ТЗ должен утвердить Заказчик, так как сдавать выполненную разработку необходимо на соответствие ТЗ. Основные риски программной разработки - несоответсвие разработанного ПО ожиданиям Заказчика. Единственный путь риск уменьшить - подписать ТЗ на старте проекта и все изменения требований (они неизбежны) - документировать.
    Успехов.

  • 25 марта 2009 в 12:43 • #
    Валерий Чесноков

    > привлеките к написанию ТЗ и договора с подрядчиком компетентного программиста, которому, по Вашему мнению эту систему предстоит поддерживать

    +1. По вашим вопросам видно, без обид, что это не ваша область, и вы в ней плаваете. В итоге, как в любой сфере, сдать человеку работу, которую он не может грамотно проверить, очень легко, и любого качества, даже самого низкого. Если я ничего не понимаю в строительстве, то сдать мне строительный объект низкого качества так же легко, как вам сайт.
    Поэтому мысль о привлечении профессионала, который будет затем поддерживать сайт, верна 100% - это специалист не даст принять брак, т.к. ему потом с ним возиться.

  • 19 марта 2009 в 07:41 • #
    Дмитрий Фоминцев

    Здравствуйте Арсений.

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

    Платформа БД: C

    При необходимости все движки и редакторы для базы данных - будут написанны индивидуально для Вас.

    Стоимость подобного проекта будет зависет от сложности ТЗ. Но могу заверить сразу - сумма небольшая для среднего бизнеса.

  • 19 марта 2009 в 13:13 • #
    Сергей Сергин

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

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

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

    Варианты конечных решений (ежели ошибусь, да поправят меня коллеги) могут лежать в диапазоне от "MySQL плюс PHP на коленке за пару дней и ХХХХ рублей" до "кластер на WebSphere и DB2 за два года и ХХХХХХ долларов"

  • 19 марта 2009 в 20:59 • #
    Николай Курманов

    Арсений, доброе время суток!
    я занимаюсь информационными разработками....
    можетте подробнее рассказать о треб базе данных???

    e-mail - #

  • 19 марта 2009 в 21:17 • #
    Вадим Потапенко

    1. все современные СУБД тянут подобную нагрузку
    2. Вам необходимо указывать требования по нагрузке, которую должно выдерживать приложение, требования по отказоустойчивости. первое формулируется примерно в терминах: X одновременно работающих пользователей, при сохранении времени отклика не более Y с или мс по желанию

    второе описывается поведение системы в случае сбоя, журналируется \ нет всякие такие детали.

    3. формулировка задания слишком асбтрактна, вам нужно более подробно описать технические требования, варианты использования системы

  • 19 марта 2009 в 22:05 • #
    Руслан Равильевич Лайшев

    Oracle RDB

  • 20 марта 2009 в 16:47 • #
    Арсений Богданов

    Большое спасибо всем за участие в обсуждении.Вероятнее всего работа будет выполняться нашим "местным" программистом.Для меня было важно грамотно оценить узловые моменты ,которые должны быть раскрыты при работе с ним.

  • 22 марта 2009 в 14:01 • #
    Степан Гавриленко

    Нужна только База данных, или интерфейс к ней ?
    Смутило выражение
    - Нужна БД для сайта-биржи.
    суть проблемы в разработке структуры, или вообще все с нуля ? сайт биржи то есть ? Подробнее о структуре и т.п в личку.

  • 24 марта 2009 в 10:39 • #
    Арсений Богданов

    База будет использоваться для работы сайта.Сайта биржи нет ,но как мне кажется главное -это эффективная база данных так как основная задача сайта это соединить потребителя информации и базу.
    Посмотрите упрощенный аналог http://www.birga.net
    требуемого.Что думаете по поводу него,насколько эффективное решение?

  • 24 марта 2009 в 16:06 • #
    Степан Гавриленко

    Посмотрел http://www.birga.net, поиск кривой, сортировок нет, ну и нужно смотреть на то как база устроена изнутри. В общем говоря, можно сделать лучше :)

  • 24 марта 2009 в 16:09 • #
    Арсений Богданов

    Согласен,считаю что сделать НУЖНО лучше:)

  • 25 марта 2009 в 12:29 • #
    Валерий Чесноков

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

  • 26 марта 2009 в 08:03 • #
    Александр Зимин

    Поддержу тех, кто за Microsoft SQL.
    ТЗ само - по себе отдельная работа, которую лучше поручить системному аналитику.
    Займет около 2х недель. - стоить будет 15 -20.
    Стоимость разработки базы для простенькой биржи 60-70 срок 2-3 недели
    Построить веб интерфейс для типовой биржи тоже 2-3 недели. стоить около 70.
    Ну и недельку я бы все это по-тестил. 10-15
    Захоститься можно в 1Gb, на первых порах. Обойдется это в 6000 руб в год.

    Итого с учетом перекрытия работ - 2 месяца и 165 штук максимум.
    Это для ТИПОВОЙ биржи. Без извращений! Например, в виде гетерогенных источников данных.

    P.S.Я бы обратил внимание на небходимость ведения бизнес-логики в СУБД и тщательного построения индексов и запросов.

  • 1 апреля 2009 в 07:28 • #
    Сергей Нырков

    Я думаю цифры павдоподобные, но это нижная граница

  • 1 апреля 2009 в 09:53 • #
    Александр Зимин

    Совершенно верно. Это именно для самого наипростейшего случая.

  • 28 марта 2009 в 00:36 • #
    Валентин Иванов

    Здравствуйте!
    1. БД Oracle XE - бесплатная
    2. Исполнителю, для реализации Вашей задачи, в ТЗ необходимо указать структуру и классификацию данных в соответствии с Вашей логикой. Требование к исполнителю - программировать БД в соответствии с промышленным стандартом Oracle.
    3. Стоимость от 1000USD, от 2 недель.

  • 1 апреля 2009 в 12:41 • #
    Михаил Сидоров

    Ну тут очень интересный вопрос. Эта Субд предназначена для ознакомления и сильно урезана по мощности. Если бд будет интенсивно использоваться то этот вариант не пройдет. Кроме того Бд для сайта. А где вы найдете хостинг бд на оракле?

  • 1 апреля 2009 в 15:21 • #
    Валентин Иванов

    Уважаемый Михаил! Согласен с Вами.Но Вы видите какой серьезный человек задает вопрос. Цитирую: "Нужна БД для сайта-биржи". "Всего более 5млн позиций".При таком подходе - БД на выделенном сервере. Oracle XE - нужна только на этапе разработки. А дальше - Oracle 11 и средства анализа. Обратите внимание - цена вопроса поднятого в топике значения не имеет. Главное качество.

  • 7 апреля 2009 в 14:21 • #
    Арсений Богданов

    Можете ли просветить :вообще показатель 5млн позиций это много или мало для БД
    с 2000 удаленных пользователей?По современным меркам ,сервер какой мощности(объема ) по это необходим?Что может стоить аренда такого сервера?
    Заранее благодарен,Арсений.

  • 7 апреля 2009 в 11:43 • #
    Евгений Горожанкин

    Арсений, настоятельно советую Вам ознакомиться с такой программой как Битрикс от 1С. Там уже есть готовые решения, которые Вы сами с легкостью сможете оптимизировать под свою идею сайта. И стоит по доступным ценам.

  • 8 апреля 2009 в 14:27 • #
    Михаил Сидоров

    Ну да, битрикс – портал а не специализированная система. С такой нагрузкой не справится, я думаю.
    Скажем так – 5млн записей это достаточно значительно. Быстродействие будет в плотную зависеть от качества проектирования БД. В качестве СУБД однозначно либо Oracle либо SqlServer. Покупка разработка и поддержка Oracle будет однозначно дороже. Железо… Этого вам мало кто сможет сказать, пока не известна производительность спроектированной БД. Могу привести пример с прошлого проекта. В день было приблизительно 200 – 300 тыс. обращений к БД. Нагрузку держал сервер 4- двуядерных процессора и 12 гб. оперативки. В таблицах лежало около 36 млн. записей, распределенных по нескольким таблицам.

  • 18 апреля 2009 в 22:24 • #
    Дмитрий Олейник

    mssql или можно попробовать на firebirdsql (www.firebirdsql.org)

    гибкость языка firebird2.5 сильно ускорит разработку, в качестве среды разработки IBExpert

    firebird очень производительный движок

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