Menu
Community /Pin to ProfileBookmark
@NogDogDec 03.2021 — #
I would re-think that, instead including a manufacturer table with foreign keys to it where applicable.
Any of the major players can handle that amount fine (as long as you index things correctly). MySQL would be fine, though I prefer PostgreSQL for reasons other than performance (maybe mostly because I work with it every day?), though it performs at least equally well.
REST could make sense if simply because so many server-side language frameworks support it out of the box. If, however, you expect requests to be fairly complex, I might look into JSON:API as an option. (I'm not terribly familiar with it, but my understanding is it's particularly useful for dealing with complex requests.)@NogDogDec 04.2021 — #
Hmm...not familiar with this. The app I work on uses PostgreSQL (on an AWS RDS instance) hit by 3 web servers with up to 1500 requests per minute in peak hours (and more than a few of those requests make more than one query). Again, not saying Postgres is better than MySQL, but that as far as I know you should be fine with either (unless one has some specific capability you want to leverage).
PS: We do run Postgres with the PGBouncer connection handler, which does help prevent occasional lags when new connections would need to be spun up otherwise.
Web-API many queries
I’m working on a new project and struggling with the right setup.
Topic is a database of products of a specific branch/industry sector, where producers can register their products (Article No., Description, Price, etc.) on a website (csv-upload for example).
Different software providers of the branch/industry sector should then be able to implement the API so the users can lookup the products.
Because of the potential huge amount of queries and the different programs I’m not really sure which type of API should be used for the best performance and compatibility of different software developed in different languages.
My first thought would be a REST API which can be handled by nearly all development environments, would you recommend that?
And which database type would be the best for data amount of more than 2-3 M. entries (additional with different table joins because of separation of manufacturer and items). And many different queries of the software users also the same time.
**1) Which type of API is recommended? (REST-API?)
2) Which type of database is recommended for performance?
3) Is there a server sided must have?
Thank you very much in advance for your thoughts,
Christian
Sign in
to post a comment7 Comments(s) ↴
0
@NogDogDec 03.2021 — #>@Change#1640138 additional with different table joins because of separation of manufacturer and items
I would re-think that, instead including a manufacturer table with foreign keys to it where applicable.
>@Change#1640138 And which database type would be the best for data amount of more than 2-3 M. entries
Any of the major players can handle that amount fine (as long as you index things correctly). MySQL would be fine, though I prefer PostgreSQL for reasons other than performance (maybe mostly because I work with it every day?), though it performs at least equally well.
>@Change#1640138 Which type of API is recommended? (REST-API?)
REST could make sense if simply because so many server-side language frameworks support it out of the box. If, however, you expect requests to be fairly complex, I might look into JSON:API as an option. (I'm not terribly familiar with it, but my understanding is it's particularly useful for dealing with complex requests.)
0
@NogDogDec 04.2021 — #>@Change#1640170 problem with postgress is the memory lack
Hmm...not familiar with this. The app I work on uses PostgreSQL (on an AWS RDS instance) hit by 3 web servers with up to 1500 requests per minute in peak hours (and more than a few of those requests make more than one query). Again, not saying Postgres is better than MySQL, but that as far as I know you should be fine with either (unless one has some specific capability you want to leverage).
PS: We do run Postgres with the PGBouncer connection handler, which does help prevent occasional lags when new connections would need to be spun up otherwise.