Servir a una gran base de usuarios con datos confiables, consistentes y de baja latencia es un desafío muy difícil para cualquier equipo de back-end. En Ledger, tomamos la decisión estratégica de alojar nuestros propios servicios de datos centrales de blockchain. Al no depender de terceros, podemos administrar los datos de nuestros clientes nosotros mismos, asegurando que los procesos subyacentes cumplan con nuestras pautas de seguridad y objetivos de nivel de servicio (SLO) orientados al rendimiento.
Pero esta estrategia también trae su propio conjunto de desafíos.
Nuestro primer desafío es migrar estos servicios básicos de suministro de datos lejos de las geniales y brillantes herramientas noSQL. En este artículo, profundizaré en por qué tomamos esta difícil decisión, las complejidades que enfrentamos y los beneficios que cosechamos.
El objetivo de este artículo es mostrar los aspectos técnicos que nos llevaron a elegir PostgreSQL como nuestra nueva capa de almacenamiento de referencia para datos de blockchain.
Inmersión profunda en los datos de Blockchain
Los datos de blockchain tienen varias características clave.
En primer lugar, está en constante crecimiento y nunca se elimina nada de él. Sin embargo, en la práctica, aunque la mayor parte de una cadena de bloques es inmutable, la parte más joven de la cadena de bloques puede cambiar debido a conflictos que deben resolverse. De hecho, como la cadena es una red de igual a igual, varios bloques legítimos pueden coexistir temporalmente. Por lo general, se elimina el más antiguo, lo que da como resultado lo que llamamos una reorganización. Para resumir, los datos se dividen entre una cola fría inmutable y un estado mental que rara vez cambia.
El problema que estamos tratando de resolver es que, si bien las cadenas de bloques son excelentes para tener datos bizantinos tolerantes a fallas, son menos efectivos para dividirlos en muchos ejes. Es decir, obtener la lista de operaciones que afectaron una cuenta es muy difícil. Incluso obtener un saldo de cuenta en una cadena de bloques como bitcoin es un desafío cuando aún no tiene la lista de transacciones.
Para superar estos desafíos, Ledger Explorer Services indexa toda la cadena de bloques. Es un servicio grande, crítico y sensible al rendimiento escrito completamente en Scala, utilizando el efecto gatos tiempo de ejecución de alto rendimiento. Tenemos más de 10k rps en bitcoin, mientras mantenemos una latencia p95 de cola por debajo de 100ms. También estamos reclutando 😊.
Un poquito de historia
Al comienzo de nuestra historia, mucho antes de que me uniera a la empresa, la capa de servicio de datos de Ledger estaba a cargo de una base de datos Neo4j integrada. Cada caja de servicio indexaba sus propios datos y los servía localmente, lo que causaba muchos problemas.
No se garantizaba la coherencia de los datos entre las instancias, y el tamaño total del estado que debía indexarse, combinado con el uso de memoria RAM y disco neo4j, no era escalable. Este problema solo empeoró a medida que la empresa crecía, lo que hacía cada vez más difícil generar nuevas instancias.
Cassandra luego fue elegido como el principal impulsor de esta nueva configuración: es una base de datos agrupada y escalable horizontalmente que está en el lado AP del teorema CAP. Resuelve los problemas relacionados con el intercambio de datos y permite una separación clara entre la indexación, el componente consciente de blockchain y los servidores API sin cabeza.
Pero, ¿cuál es el sentido de tener todo el estado histórico disponible si nunca vamos a leer de él?
Con respecto a nuestro caso de uso, rara vez se necesitan datos históricos sin procesar porque el estado de la cuenta de nuestro usuario se puede agregar a partir de ellos. Esto nos llevó a desafiar la solución de almacenamiento de datos existente que se basa en la base de datos distribuida de Cassandra.
El volumen de datos que necesitamos almacenar por blockchain, aunque en el rango de terabytes, no es lo que se puede llamar "big data". Además, la parte de si se usará para responder a la mayoría de las consultas (también conocida como la ruta activa) es aún más pequeña. Hoy en día, uno puede encontrar fácilmente servidores de hardware básicos con más de 16 TB de almacenamiento SSD NVMe. El escalado vertical es una herramienta muy poderosa, y una base de datos relacional también lo es.
Finalmente, el principal problema que tuvimos con la configuración actual de Cassandra no fue el modelo de almacenamiento derrochador ni el caso de uso de datos mal ajustado, sino la falta de facilidad de uso para los desarrolladores. El desarrollo de una nueva función basada en datos en cassandra ha demostrado ser un proceso innecesariamente lento. Nos esforzamos por implementar cada nuevo eje en el que necesitamos proporcionar datos.
Dada la experiencia de nuestro equipo en habilidades de modelado de datos y dominio de SQL, PostgreSQL era el candidato perfecto. Esta solución está probada en batalla, es robusta y fácil de ampliar, lo que la convierte en una opción ideal.
Por qué elegimos SQL sobre NoSQL:
- Lee/escribe saldos: el caso de uso de datos de la cadena de bloques se ha sesgado fuertemente en lecturas en lugar de escrituras (la cadena de bloques escribe muy pocos datos a un ritmo muy razonable, incluso para una cadena de bloques como Polygon). Cassandra tiene la capacidad de absorber una gran cantidad de escrituras: la ruta de lectura es en realidad por más tiempo que la ruta de escritura.
- Soporte de indexación: Los índices son un componente clave de un DBMS para responder consultas y nuevos casos de negocios u oportunidades. Cassandra tiene soporte limitado para la indexación. Los índices solo son efectivos si la consulta ya especifica una forma de restringir la partición en la que se ejecutará la consulta. Nosotros pagamos aquí el costo de tener un distribuido arbitrariamente base de datos. El soporte de PostgreSQL para índices es eficiente, extensible y en el borde.
- Soporte de agregación: Mismo caso para la agregación; dado que Cassandra no permite la agregación de múltiples particiones y no tolera la cláusula GROUP BY en su lenguaje de consulta, su soporte es algo deficiente. PostgreSQL propone un amplio soporte de agregación, incluso en tipos de datos exóticos como rangos y blobs jsonb.
- Modelado de datos: Cassandra es muy, muy limitante en la forma en que es posible el modelado de datos. Se debe crear una tabla para casi cada solicitud que desee responder, y los datos deben desnormalizarse en filas grandes (utilizando completamente el tienda de columna ancha aspecto de C* y también el hecho de que los escritores son muy baratos). PostgreSQL nos permite aprovechar el aspecto relacional de la cadena de bloques (llamadas, transacciones, bloques) y liberar espacio en disco, fomentando la reutilización de datos.
- Consultas y auditorías ad-hoc: Ser capaz de usar el estándar completo de SQL y hacer consultas arbitrarias significa que podemos explorar y buscar la posible causa raíz del error o tener datos exploratorios para futuros casos de uso. Realmente podemos usar la base de datos como una herramienta interactiva e inteligente en lugar de un almacenamiento tonto. Hacerlo en Cassandra sin un extenso y costoso clúster de cómputo de análisis como Presto, Spark, etc. (y como estamos ejecutando en servidores bare metal, no tenemos acceso a herramientas de análisis de datos distribuidas que se generan fácilmente como EMR).
- el uso del almacenamiento: La suposición de Cassandra es que el almacenamiento es muy económico y que el clúster se puede ampliar fácilmente con nuevas máquinas. Eso significa que todas las limitaciones tanto en índices como en agregaciones deben pagarse con almacenamiento. La falta de índices globalmente eficientes y el soporte de unión significa que tenemos que desnormalizar y almacenar una copia de la tabla completa para cada eje que queremos consultar. PostgreSQL nos ahorra terabytes de almacenamiento.
- Consistencia: Como Cassandra es una base de datos distribuida orientada a AP (la comunicación se realiza con chismes entre nodos), la consistencia es solo eventual en términos de escrituras. Puede ajustar la política de consistencia de cada declaración para lecturas y escrituras, pero el objetivo de esta base de datos nunca fue tener una consistencia sólida. PostgreSQL tiene una sólida historia de uso para misiones críticas y es muy resistente. Estar centralizado también significa que no hay ninguna red involucrada en la ruta de escritura.
- Transacciones y MVCC:
- Transacciones: Cassandra admite solo transacciones ligeras en consultas DML. Se pueden aplicar algunos lotes (doc) pero existen numerosas advertencias, a saber, que las filas deben estar en el mismo servidor (= partición) para no tener un rendimiento horrendo.
- MVCC: Cassandra admite la marca de tiempo de fila, pero no se garantiza el MVCC completo. Una compactación puede borrar datos obsoletos y no hay forma de decirle a C* que no debería hacerlo (como, por ejemplo, con una transacción en PG).
- PostgreSQL admite un modelo MVCC sólido que garantiza una ruta de lectura coherente para nuestros usuarios.
- Modelado: PostgreSQL tiene muchas más herramientas que se usan ampliamente para operar fácilmente la base de datos. Además, una herramienta como pasarela asegura que mantenemos un fuerte control de versiones del esquema de la base de datos. Ya lo integramos con nuestro código base con éxito. No hay equivalente con este nivel de madurez en Cassandra.
- Escalabilidad horizontal: Este es el punto de venta clave de Cassandra. Simplemente agregue más máquinas a medida que se expanden sus datos. No hay equivalente para PostgreSQL, ya que la fragmentación y el particionamiento deben realizarse manualmente.
Cómo planeamos escalar
Como hemos visto, el único inconveniente de usar una configuración de Postgres es escalar tanto en lecturas como en almacenamiento. ¿Qué podemos hacer para superar esta limitación?
La primera herramienta efectiva que tenemos es segregar cada protocolo o cadena de bloques que admitimos en su propia base de datos, ya que así se puede escalar adecuadamente según el volumen y el tráfico. La segmentación por dominio comercial asegura una primera capa de escalamiento.
Al llevar este concepto más allá, también podemos segmentar datos históricos fríos en una partición temporal. Las últimas versiones de Postgres han mejorado mucho la usabilidad de las tablas particionadas, lo que podría permitir mover datos sin problemas a través de un grupo de máquinas. Por ejemplo, podríamos usar máquinas más baratas con menos poder de cómputo para albergar la mayoría de los datos históricos, mientras mantenemos gigantes robustos apilados en RAM que sirven a los usuarios para albergar tablas agregadas y las últimas operaciones de los usuarios.
Este enfoque funciona muy bien en nuestro caso de uso porque no hay claves foráneas entre particiones en el almacenamiento histórico (en última instancia, todo se adjunta al bloque). Desde la perspectiva del servidor principal, incluso se podría acceder de forma transparente a los datos históricos mediante el particionamiento y la extensión postgres_fdw.
Para ayudar a poner todo esto en su lugar, también hemos analizado la extensión TimescaleDB. Esta extensión agrega muchas funcionalidades a la línea de base de postgres, y la mayoría de estas se ajustan perfectamente a nuestros casos de uso:
- Particionamiento automático de tablas basado en una columna tipo tiempo (en nuestro caso, lo adaptamos tomando como referencia la altura de la cadena de bloques).
- Compresión automática, consciente del tipo de datos y basada en columnas de fragmentos más antiguos. Esto asegura una relación de compresión casi perfecta mediante el uso de algoritmos de última generación en datos que son muy similares.
- Agregación eficiente basada en intervalos de tiempo para calcular fácilmente saldos históricos y gráficos de datos de mercado.
Estamos apenas al comienzo de la experimentación con respecto al almacenamiento, y esto desbloquea muchos casos de uso. Prueba de conceptos usando una pequeña cantidad de datos (~10k bloques en la red principal de Ethereum, por lo tanto, alrededor de 2 días de datos) mostró una reducción del espacio en disco de hasta un 40 %.
Como hemos visto, el volumen de datos, siempre que utilicemos la estrategia correcta, no es un problema. Pero, ¿cómo escalar con el tamaño de nuestra base de usuarios?
Ya tenemos una buena ventaja aquí: indexamos todos los datos de la cadena de bloques. Por lo tanto, el almacenamiento necesario no crecerá como la cantidad de usuarios, sino como el tamaño total de la cadena de bloques. Las optimizaciones de almacenamiento y lectura son totalmente ortogonales en su resolución.
Esta configuración, combinada con la muy baja necesidad de escritura en proporción al volumen de lectura que se debe atender, es la configuración ideal para un patrón de réplica líder-seguidor de clasificación. Para mejorar aún más el rendimiento y la producción, también podemos colocar las réplicas de lectura de postgres en las mismas máquinas que los servidores API y aprovechar los sockets de dominio UNIX para omitir los viajes de ida y vuelta de la red.
Aquí hay un ejemplo de una estrategia de replicación de datos que podríamos usar para escalar nuestras lecturas. Los cuadros de color gris claro representan servidores individuales. Podemos ver aquí que los módulos de API se ubican directamente junto con las réplicas de los datos más recientes para garantizar un tiempo de transferencia mínimo entre el almacenamiento y los usuarios. Las instancias de archivo descritas anteriormente no se representan para no complicar demasiado el esquema.
Observaciones finales
Como usuario de Cassandra desde hace mucho tiempo, quiero enfatizar que es una gran base de datos en su diseño, que se adapta a una amplia variedad de aplicaciones. Desafortunadamente, la elección que se hizo en Ledger para usarlo se hizo en un caso de uso de datos que nunca se materializó.
La productividad de nuestro equipo se vio afectada, y mirando hacia los desafíos que tenemos que resolver, elegimos morder la bala y no caer en la falacia del costo hundido.
En muchos casos, sus datos no son grandes datos. Administrar la distribución de datos no es una tarea difícil en la mayoría de los casos, y las ventajas y desventajas de una base de datos distribuida completa realmente deben considerarse cuidadosamente. La consideración clave es la experiencia del desarrollador, ya que libera un tiempo valioso para construir cualquier otra cosa. Este es el caso de uso real en el que debemos invertir mucho.
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- PlatoAiStream. Inteligencia de datos Web3. Conocimiento amplificado. Accede Aquí.
- Acuñando el futuro con Adryenn Ashley. Accede Aquí.
- Compra y Vende Acciones en Empresas PRE-IPO con PREIPO®. Accede Aquí.
- Fuente: https://www.ledger.com/blog/serving-web3-at-web2-scale
- :posee
- :es
- :no
- $ UP
- 10
- 10K
- 20
- a
- capacidad
- Poder
- de la máquina
- visitada
- Mi Cuenta
- a través de
- adaptar
- add
- Añade
- adherirse
- Ventaja
- agregación
- algoritmos
- Todos
- permitir
- permite
- ya haya utilizado
- también
- Aunque
- cantidad
- an
- análisis
- Analytics
- y
- https://www.youtube.com/watch?v=xB-eutXNUMXJtA&feature=youtu.be
- cualquier
- cualquier cosa
- abejas
- aplicaciones
- aplicada
- enfoque
- adecuadamente
- Archive
- somos
- en torno a
- Arte
- artículo
- AS
- aspecto
- aspectos
- asunción
- At
- Hoy Disponibles
- conscientes
- lejos
- EJES
- Eje
- Backend
- Balance
- saldos
- bases
- basado
- Base
- BE
- porque
- esto
- antes
- Comienzo
- Gigantes
- "Ser"
- beneficios
- entre
- Big
- Big Data
- Poco
- Bitcoin
- Bloquear
- blockchain
- datos de blockchain
- cadenas de bloqueo
- Bloques
- ambas
- Box
- cajas
- Trae
- Error
- build
- pero
- by
- llamar al
- Calls
- PUEDEN
- candidato
- tapa
- estudiar cuidadosamente
- case
- cases
- Causar
- causado
- centralizado
- cadena
- Reto
- retos
- desafiante
- el cambio
- cambio
- barato
- más barato
- maquinas mas baratas
- manera?
- Elige
- eligió
- elegido
- limpiar
- Médico
- código
- base de código
- frío
- Columna
- combinado
- mercancía
- Comunicación
- compañía
- complejidades
- componente
- Calcular
- concepto
- conceptos
- consideración
- considerado
- consistente
- Frio
- Core
- Cost
- podría
- creado
- crítico
- Current
- datos
- análisis de los datos
- compartir datos
- almacenamiento de datos
- Base de datos
- Días
- Koops
- descrito
- Diseño
- Developer
- el desarrollo
- difícil
- directamente
- suciedad
- distribuidos
- dividido
- do
- sí
- "Hacer"
- dominio
- No
- Abajo
- sueño
- conductor
- dos
- e
- cada una
- pasan fácilmente
- de forma sencilla
- Southern Implants
- Eficaz
- eficiente
- más
- integrado
- enfatizar
- habilitar
- alentador
- mejorar
- garantizar
- asegura
- asegurando que
- Equivalente a
- etc.
- Etereum
- RED PRINCIPAL ETHEREUM
- Incluso
- eventual
- NUNCA
- Cada
- todo
- ejemplo
- existente
- aves
- se expande
- experience
- Experiencia
- explorar
- explorador
- ampliar
- extensión
- en los detalles
- hecho
- Otoño
- Feature
- Caracteristicas
- pocos
- Encuentre
- Nombre
- cómodo
- extranjero
- adelante
- amabilidad
- en
- ser completados
- completamente desarrollado o establecido
- completamente
- funcionalidades
- promover
- futuras
- conseguir
- dado
- En todo el mundo
- objetivo
- va
- gráficos
- gris
- maravillosa
- Grupo procesos
- Crecer
- Creciendo
- garantia
- orientaciones
- tenido
- Difícil
- Materiales
- Tienen
- es
- cabeza
- fuertemente
- altura
- ayuda
- esta página
- Alta
- altamente
- histórico
- fortaleza
- HOT
- más caliente
- Cómo
- Como Hacer
- Sin embargo
- HTML
- HTTPS
- i
- ideal
- if
- inmutable
- impactados
- implementación
- mejorado
- in
- cada vez más
- índice
- Indices
- ejemplo
- COMPLETAMENTE
- interactivo
- dentro
- Invertir
- involucra
- cuestiones
- IT
- SUS
- únete
- se unió a
- jpg
- solo
- acuerdo
- Clave
- claves
- Tipo
- Falta
- idioma
- large
- Estado latente
- más reciente
- .
- LED
- Libro mayor
- legítima
- menos
- Nivel
- Apalancamiento
- luz
- ligero
- como
- la limitación
- limitaciones
- Limitada
- Lista
- pequeño
- localmente
- Largo
- miró
- mirando
- Lote
- Baja
- Máquinas
- hecho
- Inicio
- mainnet
- mantener
- Mayoría
- Realizar
- gestionan
- administrar
- a mano
- muchos
- Mercado
- Datos del mercado
- madurez
- max-ancho
- Puede..
- significa
- metal
- migrado
- mínimo
- misiones
- modelo
- modelado
- más,
- Por otra parte
- MEJOR DE TU
- movimiento
- mucho más
- debe
- a saber
- hace casi
- ¿ Necesita ayuda
- Neither
- del sistema,
- nunca
- Nuevo
- agradable
- no
- nodos
- nada
- número
- numeroso
- ,
- of
- on
- ONE
- , solamente
- funcionar
- Operaciones
- Del Mañana
- or
- solicite
- nuestros
- nosotros mismos
- Más de
- Superar
- EL DESARROLLADOR
- dinero
- parte
- partes
- camino
- Patrón de Costura
- Pagar
- pares
- de igual a igual
- perfecto
- actuación
- la perspectiva
- Colocar
- plan
- Platón
- Inteligencia de datos de Platón
- PlatónDatos
- vainas
- punto
- política
- Polígono
- posible
- Postgresql
- posible
- industria
- poderoso
- Problema
- en costes
- productividad
- prueba
- proporción
- propone
- protocolo
- probado
- proporcionar
- previsto
- poner
- consultas
- RAM
- distancia
- Rate
- más bien
- proporción
- Crudo
- Leer
- real
- realmente
- mejor
- reducción
- con respecto a
- relacionado
- confianza
- reorganización
- responder
- replicación
- representar
- representado
- solicita
- resistente
- Resolución
- resuelto
- resultante
- reutilizar
- Derecho
- robusto
- raíz
- redondo
- FILA
- Ejecutar
- correr
- mismo
- Scala
- escalable
- Escala
- la ampliación
- sin problemas
- Buscar
- EN LINEA
- ver
- visto
- segmento
- segmentación
- vender
- punto de venta
- de coches
- Servicios
- servicio
- set
- Configure
- Varios
- sharding
- compartir
- En Corto
- Mostrar
- lado
- similares
- desde
- soltero
- Tamaño
- habilidades
- chica
- menores
- inteligente
- So
- a medida
- RESOLVER
- Resuelve
- algo
- Espacio
- Spark
- Desovar
- SQL
- estándar
- Estado
- Posicionamiento
- STORAGE
- tienda
- Historia
- Estratégico
- Estrategia
- fuerte
- se mostró plenamente
- Con éxito
- SOPORTE
- soportes
- mesa
- ¡Prepárate!
- toma
- Tarea
- equipo
- Técnico
- les digas
- términos
- que
- esa
- El
- El bloque
- El Estado
- su
- luego
- Ahí.
- Estas
- ellos
- Código
- tercero
- así
- rendimiento
- equipo
- a
- demasiado
- del IRS
- Total
- TOTALMENTE
- tráfico
- transaccional
- Transacciones
- transferir
- transparentemente
- tipo
- tipos
- Finalmente, a veces
- bajo
- subyacente
- Desafortunadamente
- UNIX
- desbloquea
- innecesariamente
- us
- usabilidad
- Uso
- utilizan el
- caso de uso
- usado
- Usuario
- usuarios
- usando
- generalmente
- Valioso
- variedad
- vertical
- muy
- volumen
- quieres
- fue
- Camino..
- we
- Web2
- Web3
- WELL
- ¿
- Que es
- cuando
- que
- mientras
- Aunque que la
- todo
- porque
- amplio
- extensamente
- seguirá
- sin
- funciona
- escribir
- escrito
- Usted
- El más joven
- tú
- zephyrnet