¿La mejor manera de escalar una BD?

[coderyoruga]

Buenas!!
Tengo en pleno desarrollo una aplicación Web que básicamente lleva control de stock de mercadería.
Funciona todo correcto, la duda que tengo es si será mejor realizar una Base de datos y que allí estén todos los productos (por supuesto, que al listarlos los filtro según el ID de cliente), o tener una Base de datos para cada cliente. Supongo esto último no me permitiría escalar mucho a largo plazo, pero no se.

Tengan en cuenta que es una Aplicación Web, por lo que tendría que ver la manera de que según el usuario logeado cambien las credenciales para acceder a dicha BD.

¿Sugerencias?

[Master of the Wind]

A que te referis con "escalar"?

Desde ya te digo que una base para cada cliente es buscar problemas, sobretodo si en algun momento vas a querer consolidar la info.

[coderyoruga]

A que te referis con "escalar"?
Me refería a si el día de mañana aumentan los clientes, si sería conveniente seguir cargando y cargando una misma BD con artículos de todos ellos.
Si, ya se, eso no tiene que ver con escalar jajaja


Desde ya te digo que una base para cada cliente es buscar problemas, sobretodo si en algun momento vas a querer consolidar la info.
Lo tendré en cuenta. :cool:

[Master of the Wind]

Eso no te tiene que preocupar. Si vos dividis en varias bases, tenes que hacer que sean federadas (o sea, que esten configuradas para sacar info de varias bases de datos en una query, por ejemplo), y eso es complicado a veces, da mucha carga, y no todos los motores lo soportan (mysql por ejemplo, no).

Lo que tiene que preocuparte es la respuesta de esa base.

Si tenes 10000000 de personas, tenes ese numero y punto. Hay pocas cosas de diseño que puedas hacer para mejorar ahi.

Lo que si, pagina las consultas (en vez de tirar un select * que te traiga todo eso, traete de 10 en 10, y eso mostras en la pagina), agrega indices, por ejemplo, si usas mysql ajusta los buffers de innodb, cachea las queries desde la aplicacion con redis o memcached, replica en varios servers para balancear lectura/escritura.

Hay un lote de cosas que podes hacer ahi.

[coderyoruga]

Eso no te tiene que preocupar. Si vos dividis en varias bases, tenes que hacer que sean federadas (o sea, que esten configuradas para sacar info de varias bases de datos en una query, por ejemplo), y eso es complicado a veces, da mucha carga, y no todos los motores lo soportan (mysql por ejemplo, no).

Lo que tiene que preocuparte es la respuesta de esa base.

Si tenes 10000000 de personas, tenes ese numero y punto. Hay pocas cosas de diseño que puedas hacer para mejorar ahi.

Lo que si, pagina las consultas (en vez de tirar un select * que te traiga todo eso, traete de 10 en 10, y eso mostras en la pagina), agrega indices, por ejemplo, si usas mysql ajusta los buffers de innodb, cachea las queries desde la aplicacion con redis o memcached, replica en varios servers para balancear lectura/escritura.

Hay un lote de cosas que podes hacer ahi.

Tenía la preocupación de cantidad de registros que se podrían almacenar, pero por lo que me decís no me preocupo entonces. De todas maneras una vez arranque a vender iré ampliando servidores.

Ya tengo casi todo pronto para usar una BD sola, asíque sigo por ese cmaino entonces. :cool:

[Master of the Wind]

Lo otro que podes hacer si tenes grandes cantidades de datos, es particionar las tablas. Por ejemplo, los registros mas consultados, mas nuevos, o con ultima fecha de ingreso en una columna (todos criterios creables por el administrador) los guardas en un storage rapido como una bala (SSD, o RAID de SSDs), y los menos consultados los guardas en un storage menos rapido, como un disco mecanico.


Igual, eso te sirve si pasas los millones de registros es una tabla recien.

Tambien te conviene evaluar si todas tus tablas van a ser relacionales, o podes hacer cosas con NoSQL.

[Thalios]

igual creo que lo que quiere hacer no esta muy bien.


Entiendo que lo que quiere hacer es tener una tabla productos por ejemplo que sea asi:



Id
Producto
precio
cliente


1
Harina 000
34
Tata


2
Harina 000
36
Disco


3
Jamon
50
Devoto


4
arroz
45
alto sur




Entonces cuando entre tata y vaya a ver los productos que tiene cargados, le traiga la harina 000 a 34. Pero si el que entra a ver sus productos es el disco, lo muestre a 36


Vos decis que es una buena práctica eso? por mas que sea un saas no se debería separar los datos? pregunto porqee no lo se, pero sobre todo por seguridad por ejemplo

[Master of the Wind]

Yo lo que le entendi era una base de datos directamente para cada cliente, no una tabla. Que igual, una tabla por cada cliente tambien es una chanchada, sobretodo porque si tenes mañana 300.000 clientes, tene 300.000 tablas es un desporoposito, las tablas estan hechas para tener mucha informacion. Si tenes diferencia las reflejas en el contenido, no en otra otra tabla.


Si es como vos decis, problemas de seguridad no tendria, pero si de integridad. Tendria que normalizar esa tabla y partirla en 3: cliente, producto y una relacion tiene, con el precio asignado en la relacion.

[coderyoruga]

igual creo que lo que quiere hacer no esta muy bien.


Entiendo que lo que quiere hacer es tener una tabla productos por ejemplo que sea asi:



Id
Producto
precio
cliente


1
Harina 000
34
Tata


2
Harina 000
36
Disco


3
Jamon
50
Devoto


4
arroz
45
alto sur




Entonces cuando entre tata y vaya a ver los productos que tiene cargados, le traiga la harina 000 a 34. Pero si el que entra a ver sus productos es el disco, lo muestre a 36
Exactamente eso, ojalá con esos clientes jajaja, pero si, esa es la idea general.


Yo lo que le entendi era una base de datos directamente para cada cliente, no una tabla. Que igual, una tabla por cada cliente tambien es una chanchada, sobretodo porque si tenes mañana 300.000 clientes, tene 300.000 tablas es un desporoposito, las tablas estan hechas para tener mucha informacion. Si tenes diferencia las reflejas en el contenido, no en otra otra tabla.

Si es como vos decis, problemas de seguridad no tendria, pero si de integridad. Tendria que normalizar esa tabla y partirla en 3: cliente, producto y una relacion tiene, con el precio asignado en la relacion.
Claro, una alternativa era una BD por cada cliente, pero de ser así, algún cambio, por ejemplo, en el nombre de una columna, ya no sería muy práctico que digamos hacerlo en todas las BD.

No se me ocurre un método alternativo entre una manera y la otra.

[Thalios]

Yo lo que le entendi era una base de datos directamente para cada cliente, no una tabla. Que igual, una tabla por cada cliente tambien es una chanchada, sobretodo porque si tenes mañana 300.000 clientes, tene 300.000 tablas es un desporoposito, las tablas estan hechas para tener mucha informacion. Si tenes diferencia las reflejas en el contenido, no en otra otra tabla.


Si es como vos decis, problemas de seguridad no tendria, pero si de integridad. Tendria que normalizar esa tabla y partirla en 3: cliente, producto y una relacion tiene, con el precio asignado en la relacion.


Si si, me referia asi a lo bruto, sin normalizar ni nada para efectos de practicidad nomas

[Master of the Wind]

Igual te digo, y no es porque te quiera a tirar abajo. Con la mayoria de las bases de datos de aplicaciones para Uruguayos, nunca vas a tener el problema de tener que particionar, dividir, escalar aca o escalar alla.

Salvo que me digas que es para Tienda inglesa, devoto, tata o algo asi.

[coderyoruga]

Igual te digo, y no es porque te quiera a tirar abajo. Con la mayoria de las bases de datos de aplicaciones para Uruguayos, nunca vas a tener el problema de tener que particionar, dividir, escalar aca o escalar alla.

Salvo que me digas que es para Tienda inglesa, devoto, tata o algo asi.

Ah no no, es apuntado a comercios chicos y medianos. No porque no quiera apuntar a lo grande, si no porque ellos ya tienen empresas contra las cuales de momento no puedo competir.

[el_cami90]

Puede ser que a lo que te estes refiriendo sea al concepto de multi-tenancy?

Hace un tiempo tuve un proyecto donde el software era el mismo para cada cliente, pero cada uno con su BD y cada uno entraba por su dominio. Hay distintos tipos de multi-tenancy y cada una se adapta a diferentes necesidades

[Thalios]

Por poner un ejemplo choto, en Travel Leaders usabamos Rackspace (webmails para las franquicias).

Si tirabamos la consulta select * from webmailaccounts (totalmente simplificado para el ejemplo siga siendo choto)

Nos traia todos nuestros webmails y los datos que estaban en esa tabla.


Si entraba con el usuario de vacation.com (eraadmin de ambos) y tiraba la misma query, me traía todos los datos de las cuentas de vacation.com





Vos decis que si un admin tira la misma query está bien que le traiga los datos de travel leaders y de vacation.com con una columna mas especificando de qué cliente es?


O tiene que estar más segmentado eso? es pregunta posta, no tengo claro cómo manejar algo así, siempre que arme tablas era un cliente único y no me enfrente con ese tema.

[Master of the Wind]

Puede ser que a lo que te estes refiriendo sea al concepto de multi-tenancy?

Hace un tiempo tuve un proyecto donde el software era el mismo para cada cliente, pero cada uno con su BD y cada uno entraba por su dominio. Hay distintos tipos de multi-tenancy y cada una se adapta a diferentes necesidades


Creo que el lo quiere mas para su lado y no para que cada cliente entre, por eso no se me ocurrio eso, si asi fuera, seria ideal eso entonces.



Por poner un ejemplo choto, en Travel Leaders usabamos Rackspace (webmails para las franquicias).

Si tirabamos la consulta select * from webmailaccounts (totalmente simplificado para el ejemplo siga siendo choto)

Nos traia todos nuestros webmails y los datos que estaban en esa tabla.


Si entraba con el usuario de vacation.com (eraadmin de ambos) y tiraba la misma query, me traía todos los datos de las cuentas de vacation.com





Vos decis que si un admin tira la misma query está bien que le traiga los datos de travel leaders y de vacation.com con una columna mas especificando de qué cliente es?


O tiene que estar más segmentado eso? es pregunta posta, no tengo claro cómo manejar algo así, siempre que arme tablas era un cliente único y no me enfrente con ese tema.

Ahi estas hablando de SQL puro o consulta mediante un panel web?

[Thalios]

En mi caso teniamos acceso a sql que nos disponibilizaba RS, pero así sea por panel web, siempre pensé que se debía separar la info, puedo tener el concepto mal claramente

[Master of the Wind]

Pueden ser muchas cosas entonces, por ejemplo, podes poner un Proxy SQL entre medio y en base a credenciales parametrizar las queries. Tambien hay wrappers y middlewares para bases de datos cuando tenes cosas como particiones, federacion o requerimientos de seguridad complejos de todos colores y tipo.

En general, siempre depende de la escala que estes hablando, y de la forma de acceder a la info.

Si es muy grande, y tenes un set de datos complejo, pero a su vez ese set de datos no se va a cruzar entre si con otra info recurrentemente, y podes separarlo tranquilamente, pero tambien porque puede pasar al momento de generarlo sea una infra/procesos/contenedores aparte tambien.

Ya son puntos que dependen mucho de la arquitectura del software, de servicios y los requerimientos de ingenieria. No hay receta, tenes mil formas de hacerlo.

[coderyoruga]

Puede ser que a lo que te estes refiriendo sea al concepto de multi-tenancy?


Hace un tiempo tuve un proyecto donde el software era el mismo para cada cliente, pero cada uno con su BD y cada uno entraba por su dominio. Hay distintos tipos de multi-tenancy y cada una se adapta a diferentes necesidades
Seguramente me sirva si, de todas maneras para no complicarme tanto de entrada voy a hacer todo en una sola BD, después el tiempo lo dirá.



Por poner un ejemplo choto, en Travel Leaders usabamos Rackspace (webmails para las franquicias).


Si tirabamos la consulta select * from webmailaccounts (totalmente simplificado para el ejemplo siga siendo choto)


Nos traia todos nuestros webmails y los datos que estaban en esa tabla.




Si entraba con el usuario de vacation.com (eraadmin de ambos) y tiraba la misma query, me traía todos los datos de las cuentas de vacation.com




Vos decis que si un admin tira la misma query está bien que le traiga los datos de travel leaders y de vacation.com con una columna mas especificando de qué cliente es?




O tiene que estar más segmentado eso? es pregunta posta, no tengo claro cómo manejar algo así, siempre que arme tablas era un cliente único y no me enfrente con ese tema.



Pueden ser muchas cosas entonces, por ejemplo, podes poner un Proxy SQL entre medio y en base a credenciales parametrizar las queries. Tambien hay wrappers y middlewares para bases de datos cuando tenes cosas como particiones, federacion o requerimientos de seguridad complejos de todos colores y tipo.


En general, siempre depende de la escala que estes hablando, y de la forma de acceder a la info.


Si es muy grande, y tenes un set de datos complejo, pero a su vez ese set de datos no se va a cruzar entre si con otra info recurrentemente, y podes separarlo tranquilamente, pero tambien porque puede pasar al momento de generarlo sea una infra/procesos/contenedores aparte tambien.


Ya son puntos que dependen mucho de la arquitectura del software, de servicios y los requerimientos de ingenieria. No hay receta, tenes mil formas de hacerlo.


La idea es que cada cliente entre desde un mismo dominio: www.nombre-app.com y ahí hacen login, y las consultas SQL las filtros según un campo pertenece_a_empresa por decir algo. Por supuesto con tablas normalizadas, y las medidas de seguridad correspondientes. Laravel por suerte ayuda mucho en ese sentido.


Al principio apuntaré a pocos clientes, por razones obvias. Con el tiempo iré ampliando. Porque si me pongo a ver ahora todo lo que le podría agregar se ma va a hacer eterno y no lanzo mas la App.

[Master of the Wind]

Si necesitas un ingeniero DevOps o un SRE pega el grito (el pior era el tipo)

[coderyoruga]

Si necesitas un ingeniero DevOps o un SRE pega el grito (el pior era el tipo)
¡Como no!, cuando tenga el presupuesto con gusto, jajaja


Seguramente me sirva si, de todas maneras para no complicarme tanto de entrada voy a hacer todo en una sola BD, después el tiempo lo dirá.

La idea es que cada cliente entre desde un mismo dominio: www.nombre-app.com (http://www.nombre-app.com) y ahí hacen login, y las consultas SQL las filtros según un campo pertenece_a_empresa por decir algo. Por supuesto con tablas normalizadas, y las medidas de seguridad correspondientes. Laravel por suerte ayuda mucho en ese sentido.
¿La idea en general estaría bien?

[Kamize]

Lo vas a hacer con una única tabla? O entendí mal?

[coderyoruga]

Lo vas a hacer con una única tabla? O entendí mal?
Lo terminé haciendo con una BD, con distintas tablas y sus respectivas relaciones.
Y todo cacheado para evitar que se sature todo jajaja