Въпрос за голяма база данни

M

malin_genadiev

New Member
Здравейте!
Понеже ще правя сайт с доста голяма база данни - на ден ще се публикуват минимум по 5000 записа в таблицата и се чудя как е най-добре да се направи. Дали ще има проблем ако е една таблица в базата и в нея да се добавя всичко или да се разделя по някакъв начин на отделни таблици.

Като цяло нещата ще са много прости, ще има няколко полета с различна информация и след това трябва да се търси по дата и да се сортират по различни критерии. Знам как да ги направя нещата да работят, просто се чудя като станат прекалено много записите дали няма да се товари много сървъра. Все пак ще се вкарват всеки месец по 150 000, може понякога и по 200 000 записа, което прави грубо казано 2 милиона записа годишно.
 
Здравейте,
Базата данни няма проблем да се пълни с по 5000 записа на ден. Въпросът е след това, търсене и визуализиране на записите. Трябва внимателно да се направи структурата и съответните индекси на полетата, ако е нужно да се добавят partition. Ако има релации към основната таблица нещата малко се усложняват.
 
Ще бъде с полета от сорта на id, date, product_title, product_description, price. При добавяне просто ще се вкарва нов ред с въведените данни.
След това ще има заявка към базата от сорта: select * from db where date =? AND price > 100 и тем подобни.
Като цяло не е нищо сложно, едно просто добавяне и селектиране след това. Единственото, което ме притеснява е големия обем. Не знам как точно работи базата данни - като търся по даден критерии, цялата база ли се преравя докато не се извлекат съвпаденията или се работи само по конкретните условия, като другите записи не се зареждат. Ако е първото, значи ще има проблем с многото записи, ако е второто, то тогава няма да имам проблем, понеже при всяка заявка ще се вадят максимум резултатите за месеца.
 
архитектурата на базата данни не зависи от обема информация, който ще наливаш в нея, а от начина по който ще извличаш информация от нея. Направи си картинка на взаимовръзките между таблиците и си прецени колко и какви индекси ще ползваш за да няма после куц охлювввввв на паве
 
malin_genadiev каза:
Ще бъде с полета от сорта на id, date, product_title, product_description, price. При добавяне просто ще се вкарва нов ред с въведените данни.
След това ще има заявка към базата от сорта: select * from db where date =? AND price > 100 и тем подобни.
Като цяло не е нищо сложно, едно просто добавяне и селектиране след това. Единственото, което ме притеснява е големия обем. Не знам как точно работи базата данни - като търся по даден критерии, цялата база ли се преравя докато не се извлекат съвпаденията или се работи само по конкретните условия, като другите записи не се зареждат. Ако е първото, значи ще има проблем с многото записи, ако е второто, то тогава няма да имам проблем, понеже при всяка заявка ще се вадят максимум резултатите за месеца.
Увеличете...
Както @s1yf0x също каза SELECT е важното. Един SELECT може да върне и 1 милион реда, обаче там ще ти трябва много рам памет. Затова както писах по - горе се прави разделяне на таблицата(partition, партишън) на месечна, годишна база и след това заявките ти връщат редовете в конкретен партишън, които са в пъти по - малко от цялата таблица. Работил съм върху новинарски сайт, където се наливаха голямо количество новини и положението не е толкова просто.
 
Да, за да се оптимизира и върви добре на фронта, а и на сървър сайд, няма да е зле след като направиш това, което казаха колегите горе да я тестваш няколко дни и да видиш как ще може да я оптимизираш преди да пуснеш крайния вариант, а именно да видиш критичните точки - кое куери ще се вика и изпълнява най-много и най-вече колко време му отнема. Няма нищо страшно при големите бази, ако са направени добре връзките.
 
http://stackoverflow.com/questions/3639861/why-is-select-considered-harmful
here are really three major reasons:

  • Inefficiency in moving data to the consumer. When you SELECT *, you're often retrieving more columns from the database than your application really needs to function. This causes more data to move from the database server to the client, slowing access and increasing load on your machines, as well as taking more time to travel across the network. This is especially true when someone adds new columns to underlying tables that didn't exist and weren't needed when the original consumers coded their data access.

  • Indexing issues. Consider a scenario where you want to tune a query to a high level of performance. If you were to use *, and it returned more columns than you actually needed, the server would often have to perform more expensive methods to retrieve your data than it otherwise might. For example, you wouldn't be able to create an index which simply covered the columns in your SELECT list, and even if you did (including all columns [shudder]), the next guy who came around and added a column to the underlying table would cause the optimizer to ignore your optimized covering index, and you'd likely find that the performance of your query would drop substantially for no readily apparent reason.

  • Binding Problems. When you SELECT *, it's possible to retrieve two columns of the same name from two different tables. This can often crash your data consumer. Imagine a query that joins two tables, both of which contain a column called "ID". How would a consumer know which was which? SELECT * can also confuse views (at least in some versions SQL Server) when underlying table structures change -- the view is not rebuilt, and the data which comes back can be nonsense. And the worst part of it is that you can take care to name your columns whatever you want, but the next guy who comes along might have no way of knowing that he has to worry about adding a column which will collide with your already-developed names.
But it's not all bad for SELECT *. I use it liberally for these use cases:

  • Ad-hoc queries. When trying to debug something, especially off a narrow table I might not be familiar with, SELECT * is often my best friend. It helps me just see what's going on without having to do a boatload of research as to what the underlying column names are. This gets to be a bigger "plus" the longer the column names get.

  • When * means "a row". In the following use cases, SELECT * is just fine, and rumors that it's a performance killer are just urban legends which may have had some validity many years ago, but don't now:

    SELECT COUNT(*) FROM table;
    in this case, * means "count the rows". If you were to use a column name instead of * , it would count the rows where that column's value was not null. COUNT(*), to me, really drives home the concept that you're counting rows, and you avoid strange edge-cases caused by NULLs being eliminated from your aggregates.

    Same goes with this type of query:

    SELECT a.ID FROM TableA a
    WHERE EXISTS (
    SELECT *
    FROM TableB b
    WHERE b.ID = a.B_ID);
    in any database worth its salt, * just means "a row". It doesn't matter what you put in the subquery. Some people use b's ID in the SELECT list, or they'll use the number 1, but IMO those conventions are pretty much nonsensical. What you mean is "count the row", and that's what * signifies. Most query optimizers out there are smart enough to know this. (Though to be honest, I only know this to be true with SQL Server and Oracle.)
 
Аз имам таблица с около 30 000 write и 70 000 read заявки на ден и вече около година си оперира без никакви проблеми и забавяне на скромен VPS. Както казаха вече, не би трябвало да имаш проблем, ако заявките и индексите ти са оптимизирани.
 
s1yf0x каза:
архитектурата на базата данни не зависи от обема информация, който ще наливаш в нея, а от начина по който ще извличаш информация от нея. Направи си картинка на взаимовръзките между таблиците и си прецени колко и какви индекси ще ползваш за да няма после куц охлювввввв на паве
Увеличете...
Нямаш и идея в каква голяма грешка си :)
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе